Software teams face a dilemma when they move away from traditional waterfall methods to agile methods of software development. Waterfall methods mean that software teams are required to iteratively build and integrate entire lists of system components and ensure that the components are tested well.
Even though waterfall methods are a manual process, it can be handled with fewer complexities due to the lower rate of iterative cycles.
With agile methods in play, teams follow a continuous – build, integrate and test – roadmap to continuously expand system functionalities instead of simply building components separately and assembling them together at the end.
Understanding Continuous Integration (CI) –
Multiple engineers work to develop new systems one component at a time. Every time a new component or feature is completed, the finished component will be added to the existing code. This is what is referred to as a ‘build’.
For instance, consider the following example;
A movie production team creates an initial video clip and completes the whole sequence by continuously adding new frames. Everytime a new sequence of frames are added, the producers play the movie from the beginning to check whether the whole movie still makes sense. If it does, then we can safely say, we do have a ‘green build’.
Now, let’s say an engineer adds a new piece of code to the green build. However, when the test is run (just like re-running the whole movie sequence), it turns out that the new component doesn’t fit in very well. The component doesn’t integrate and thus results in a ‘red build’. Now, the engineer who created that particular faulty piece of code has to fix it.
Previously engineers wouldn’t have wanted everyone to know that a faulty piece of code had been added to the system build. Today, however, it is the opposite.
Thanks to Continuous Integration practices the development team is informed as soon as a faulty piece of code is added to the build. Developers make use of ‘red’ and ‘green lights’ to maintain build status visibility across the team.
A red light indicates that no new piece of code is to be added until a green light is indicated.
In the case of the above example, let’s assume the team consists of 10 developers. A team of 10 developers will be adding or changing code at a rate of 50 times a day per developer. This adds up to nearly 500 builds per day, per project. This will also include the following activities for each day the project is in development:
- 500 rounds of source code downloads
- 500 rounds of source code compilations
- 500 rounds of artefact deployment
- 500 rounds of testing (i.e unit testing, regression testing)
- 500 rounds of build pass/fail notifications
This is a point where automation is called to task.
Understanding Continuous Deployment/Continuous Delivery (CD) –
CD is abbreviated for both; Continuous Deployment and Continuous Delivery. It must be emphasised that the two expansions of CD are mutually exclusive and do not mean the same thing.
Allow me to elaborate in the following example;
There are two types of television programs; the news, and a cookery show. Unlike the cookery show, the news program will have to go through a considerable number of checks prior to broadcast. Similarly, certain software domains accommodate the freedom to perform a direct release into production environments, whereas other software domains are required to make a business decision (prior approval) in order to proceed with a release into production environment.
Continuous deployment and continuous delivery both mean automating deployment and testing of a software on a regular basis to a production-like environment. However, the differences are as follows:
Continuous Deployment — A process which is fully automated and includes production deployments (no human interaction after code – commit).
Continuous Delivery — An almost fully automated process where production deployments occur with a business decision.
When following CI-CD methodologies, a pipeline typically breaks the software delivery process in to various stages. The last stage will provide feedback to the development team. Even though there isn’t a defined standard for creating a pipeline, we are able to identify the following stages:
- Build automation
- Continuous integration
- Deployment automation
- Test automation
A project may have different pipelines or even different types of pipelines for different purposes.
Let’s take a look at our options.
This leaves us with a requirement for a powerful tool which is capable of the following, using pipelines:
- Automate code builds
- Build artefacts
- Perform deployments
- Run tests
- Provision above into multiple environments (Dev, SIT, UAT/ Prep/ Prod)
This leads us to several different engines such as:
- CircleCI
- Eclipse Hudson
- GitLab CI
- JetBrains TeamCity
- ThoughtWorks GoCD
- ThoughtWorks Snap
- Jenkins
Jenkins –
Jenkins is an open CI-CD tool written using Java programming language. Since Java is platform independent, Jenkins inherits the same and will run on most platforms available today.
Jenkins commenced as a fork off the original Hudson project and has evolved since day one. Today it is among the top contenders in DevOps tool-chains because it is free, open source and modular.
Even though the functionalities of Jenkins – straight out of the box – is very limited, there are more than 1,000 plugins which enhance capabilities of Jenkins far ahead of most commercial or Foss tools.
(Jenkins interface)
Coming back to the original idea of choosing the CI-CD tool for our software projects here are some ways in which Jenkins can match our requirements,
- Automate code checkouts from repository
- Supports almost all of the existing source code repositories and can expect to support upcoming ones as well (i.e: Mercurial, Subversion, Git, CVS, Perforce, Bzr, Gerrit, Monotone, Darcs, etc.)
- Automate the build
- Supports most of the build automation tools available (i.e: Command-line, Maven, Ant, Gradle, etc.)
- Every commit should build on an integration machine
- Supports by polling as well as providing listeners to trigger builds by the SCM (i.e: Poll SCM feature, Git Hooks, etc.)
- Make the build self-testing
- Supports most of the unit testing tools/platforms through number of plugins (i.e: JUnit, NUnit, etc.)
- Test in a clone of the production environment
- Supports most of the test tools/platforms through number of plugins (i.e: JMeter, SoapUI, Selenium, Cucumber, etc.).
- Make it easy for anyone to get the latest executable version
- Supports by maintaining build execution history and through number of plugins (i.e Build history, Version Number Plugin, etc.).
- Everyone can see what’s happening
- Supports through the simplest easy-to-understand UI and build statues (i.e: Green, Red, Gray build statues, Blue Ocean project, etc.).
- Automate deployment
- Supports automation as out of the box product, build pipelines and variety of plugins (i.e: Cron Jobs, Build pipeline plugin, etc)
Conclusion –
It is not easy to emphasise enough on the importance of orchestrating, automating and streamlining development processes. Deployments themselves being tested over and over will provide for almost complete confidence in the system being built.
CI-CD is central to DevOPs, and a successful DevOps implementation may contain implications that extend beyond IT and to business itself. Continuous improvements of software continuously improves products and services.
