by Rodolfo Cordero – GlobalNow DevOps Engineer
With some agile methodologies it is common to see weekly or even more frequent deployments, with new release having amazing features or functionality important to the business. Of course it’s a priority to test the new functionality, but it is also common to neglect the adequate testing of existing functionality and less important new features. Unfortunately, this can be damaging since to find issues related to broken/bad code at the end of a sprint or worse, in production, is very costly.
We attempt to avoid the above through “DevOps” type processes such as Continuous Integration. The concept of Continuous integration is to automatically test early in the development life cycle, to reduce errors, rework, and improve overall system quality.
One of the first steps in deploying continuous integration is to create test cases. At a minimum you should identify a subset of cases for the smoke tests and implement some means of version control on them (e.g. GIT or Subversion). Of course it’s beneficial to already have a complete test plan (regression test, sanity test and unit test) implemented, but CI should focus on the cases designated for the smoke test.
Which brings us to Jenkins:
Jenkins is an open source continuous integration tool written in Java, and is a powerful tool used by many companies and projects. Some may think it may not have the best graphical interface, but Jenkins is also incredibly capable and highly scalable – and if more functionality is need, plugins are available to help.
Once you have your test cases prepared, Jenkins can help you. Jenkins can execute jobs. Jobs are like a mini project where you can define actions such as build the app with Ant or Maven, prepare the workspace of the job, execute tests, get metrics and publish the result of the execution. The jobs in Jenkins can be executed manually, by a schedule time or trigger, by other jobs, and any section may be extendable by Jenkins via a plugin.
Although there are other tools and options, I prefer Jenkins because it has the ability to integrate with different CVS, languages and frameworks – and it can be used in “nontraditional” scenarios.
Recommended CI workflow:
Step 1. When a developer performs a code change and saves the code in a control version system (for example in GIT, when a developer can do a push in the branch master, dev or qa), the control version system will notify Jenkins and if Jenkins has a job pre-configured to respond to that trigger – it starts the process.
Step 2. The next step is to prepare the environment, examples include cleaning workspaces, executing tasks or injecting environmental variables.
Step 3. When all is ready, the next natural step is the build action. In this step you can execute ANT, terminal commands, execute a third party software, run unit test or whatever you prefer.
Step 4. And the last step is the “the post build” – you can publish the build, create reports or create error notifications.
So, using Jenkins you can test code daily or whenever preferred, for every change in the CVS, and the developers will know when a test failed and be able to fix it immediately without affecting any other downstream resources. The road to successful CI is not easy, but you will most certainly see the difference in your process, results and level of system quality.