Before moving on to this topic, please allow me to recall from my first blog “Introduction to DevOps” that mentioned, “Sprints are tested only at the end of dev cycle, in which case the bugs are identified”.We also recommend our readers to go through below blogs before proceeding forth.
Introduction to Linux and subsystems
Introduction to Git
What is being emphasized in the above statement is that the sprints are executed in full steam, but there are no regular tests performed on the changes that are submitted during the sprint. Only when the tests are performed at the end of the sprint cycle, we identify any bugs. Such situations can be avoided by regularly checking the code for any bugs/regression, etc.
But how to? The solution is Continuous Integration.
What is Continuous Integration?
As per Martin Fowler, Continuous Integration is a software development practice where members of a team integrate their work frequently, usually, each person integrates at least on a daily basis – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
By integrating regularly, you can detect errors quickly and locate them more easily. Hence, you avoid the last minute stress of integration and problem rectifications.
Great! Now that you are sold on the idea of CI, let’s understand how you can actually implement that in your team.
Implementation
Implementing CI is cheap and the benefits that the teams reap are vast. Hence, the ROI on CI setup is exponentially great.
But, before you jump the gun and place an order to purchase a high-end server for your builds and tests, let’s ensure that your team follows the required best practices.
Requirements
There are 4 textbook requirements that you must fulfill in order to successfully implement CI:
- Automated Builds: Your codebase should be buildable from the command line and it should be able to successfully complete without any manual intervention.
- This essentially means that you should have adapted a build system for you project (e.g., Maven, ANT, Make, etc.) which can take care of the complex compilation tasks and produce the final output product (e.g., a deployable war file, an executable, etc.).
- Single Source Repository: Ensure that your team puts everything required for a build in the Version Control System (VCS). It is not of much importance which VCS is used, but make sure that you use one.
- Automate Tests: An integral part of CI is automated testing. Hence, it is of high importance that your team has identified and implemented an automated test system. This will be used so that your builds can be verified by your test systems. Tools like XUnit come in handy for such scenarios.
- Commit Everything: CI is primarily about communication. Integration allows developers to tell other developers about the changes they have made. Frequent communication allows people to know quickly as the changes develop.
- By committing the changes frequently, developers quickly find out if there’s a conflict between two developers. The key to fixing problems quickly is finding them quickly. With developers committing every few hours, a conflict can be detected within a few hours of it occurring, at that point not much has happened and it’s easy to resolve. Conflicts that stay undetected for weeks can be very hard to resolve.
- Fix Broken Builds Immediately: A key part of doing a CI build is that if the build fails, it needs to be fixed right away. The whole point of working with CI is that you’re always developing on a known stable base. When the build breaks, however, it’s important that it gets fixed fast.
If your team already follows the above mentioned best practices, you are already half way through setting up CI in your organization.
The first step is to identify which tool you want to use to perform the CI activities. Among the various options available, the most popular ones are Hudson, Jenkins, Bamboo, and Cruise control. If you, for some reason, do not like any of the readily available tools, you can script your own (More on that later :))
Introduction to Jenkins
Hudson was written in Java and was started as a hobby project by Kohsuke Kawaguchi way back when he was working in Sun Microsystems. Hudson had developed on Open Source Model and had a lot of contributors. Soon, Sun was taken over by Oracle, which decided to seize the “open-sourceness” of Hudson. Post this, Kohsuke moved out of Oracle and took away a forked version of Hudson with him. This was called Jenkins.
Hudson continues as an Oracle supported closed-source product. Jenkins remained open to public.
Jenkins is by far the most popular CI tool in the market as I write this blog, and is trusted by companies like Google, Facebook, etc. among others.
Jenkins provides excellent integration with various SCM tools and building and testing tools. It also has quite remarkable reporting and communication capabilities. Jenkins also features a strong security infrastructure which can be plugged into your organization’s setup (e.g., AD, LDAP, NIS, etc.)
Moreover, there are various other third party plugins available which can extend the functionality of Jenkins to provide more features and support various kinds of workflows, which can be specific to specific teams.
Next Steps
The next natural and logical evolution of CI is the CD. CD stands for continuous delivery/deployment.Continuous Delivery is an approach in which teams ensure that every change to the system is releasable and that we can release (or Deploy) any version at the push of a button. CD aims to make releases boring, so we can deliver frequently and get fast feedback on what users care about.
Continuous Deployment takes it even further. In this approach, all the changes submitted to the VCS are automatically released (or Deployed). There is no choice and it is not optional.
It goes without saying that Continuous Deployment and Delivery require extremely high-quality CI Implementation. This implies that your Builds are matured enough to build for the right target, your tests are able to cover all the use cases and the quality of checks are performed very rigorously.
Keep visiting www.acadgild.com to stay updated.
