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.
If you have a method that fails occasionally and you want to retry it a few times before throwing an exception. @RetryOnFailure from jcabi-aspects can help. For example, if you're downloading the following web page:
This method call will throw an exception only after three failed executions with a ten seconds interval between them.
There are many tools that control the quality of Java code, including Checkstyle, PMD, FindBugs, Cobertura, etc. All of them are usually used to analyze quality and build some fancy reports. Very often, those reports are published by continuous integration servers, like Jenkins.
Qulice takes things one step further. It aggregates a few quality checkers, configures them to a maximum strict mode, and breaks your build if any of them fail.
What do you think? Would it be convenient for you—to have your code rejected every time it breaks just one of 900 checks? Would it be productive for the team—to force developers to focus so much on code quality?
Rultor is a coding team assistant. Travis is a hosted continuous integration system. In this article I'll show how our open source projects are using them in tandem to achieve seamless continuous delivery.
Docker is a command line tool that can run a shell command in a virtual Linux, inside an isolated file system. Every time we build our projects, we want them to run in their own Docker containers. Take this Maven project for example:
This command will start a new Ubuntu system and execute mvn clean test inside it. Rultor.com, our virtual assistant, does exactly that with our builds, when we deploy, package, test and merge them.