When I explain how Rultor automates deployment/release processes, very often I hear something like:
But I already have a script that deploys everything automatically.
This response is very common, so I decided to summarize my three main arguments for automated Rultor deployment/release processes in one article: 1) isolated docker containers, 2) visibility of logs and 3) security of credentials.
Read about them and see what Rultor gives you on top of your existing deployment script(s).
Look at GitHub RESTful API, for example. To get information about a repository you should make a GET request to api.github.com/repos/yegor256/rultor. In response, you will get a JSON document with all the details of the yegor256/rultor repository. Try it, the URL doesn't require any authentication.
To open the same repository in a nice HTML+CSS page, you should use a different URL: github.com/yegor256/rultor. The URL is different, the server-side is definitely different, but the nature of the data is exactly the same. The only thing that changes is a representation layer.
In the first case, we get JSON; in the second—HTML.
How about combining them? How about using the same URL and the same server-side processing mechanism for both of them? How about shifting the whole rendering task to the client-side (the browser) and letting the server work solely with the data?
Docker starts a process inside its container as a "root" user. In some cases, this is not convenient though. For example, initdb from PostgreSQL doesn't like to be started as root and will fail. In rultor.com, a DevOps team assistant, we're using Docker as a virtualization technology for every build we run.
Here is how we change the user inside a running container, right after it is started.
When I deploy a new version of stateful.co, a Java web application, to CloudBees, it takes 30 seconds of my time. Maybe even less. Recently, I deployed version 1.6.5. You can see how it all happened, in GitHub issue #6:
As you see, I gave a command to Rultor, and it packaged, tested and deployed a new version to CloudBees. I didn't do anything else.
Now let's see how you can do the same. How you can configure your project so that the deployment of its new version to CloudBees takes just a few seconds of your time.
"The Art of Software Testing" by Glenford J. Myers, Tom Badgett and Corey Sandler is one of my favorite books concerning testing and software engineering in general. In this article, I will provide an overview of the book, as well as highlight the ideas and quotes that I found to be the most interesting.
When I release a new version of jcabi-aspects, a Java open source library, to Maven Central, it takes 30 seconds of my time. Maybe even less. Recently, I released version 0.17.2. You can see how it all happened, in GitHub issue #80:
As you see, I gave a command to Rultor, and it released a new version to Maven central. I didn't do anything else.
Now let's see how you can do the same. How you can configure your project so that the release of its new version to Maven Central takes just a few seconds of your time.