Continuous Integration with Agile
By Neha Vaidya, Community Contributor - September 30, 2020
The quality of software depends on the quality of its development. However, to reach the desired product quality, development plans and methods may deviate from the original estimations. Customer requirements also tend to change with time. Any system that accommodates these changes and implements them successfully is bound to create better software.
This is precisely what the Agile development methodology does. This article will focus on a particular pivotal stage in agile development – Continuous Integration.
Let’s begin with a glimpse of pre-Agile models, AKA the traditional Software Development Life Cycle (SDLC) models.
Traditional SDLC models
The process through which software is developed is termed the SDLC – Software Development Life Cycle. It is the blueprint that defines the various steps to be followed to build software.
The Waterfall Model and Spiral Model were two frequently used traditional SDLC models. The Waterfall Model comprises a step by step approach – moving through requirements gathering, design, implementation, testing, and maintenance in a linear fashion. This model did not work well when customers expected changes because it provided little scope to include modifications once the design phase was finished.
To counter this, many organizations started following the Spiral Model of SDLC. In this model, the first cycle began with building an initial prototype: the Minimum Viable Product (MVP). Based on this, the customer would be given a chance to suggest any necessary changes. If changes were indeed recommended, all the SDLC stages would be followed to build a second prototype.
The advent of Agile
Until the early ’80s, the software would be developed based on the principles of physical engineering. During this time, the demand for automation in mechanical processes skyrocketed, leading to fierce competition among the software development companies. Traditional SDLCs were simply inadequate, as they often took far too much to deal with any deviations from initial requirements.
End products were not stable enough and kept failing to meet customer expectations. Naturally, the software development fraternity required an SDLC model that solved the problems mentioned above. The new model would have to maintain the positives of traditional SDLCs and adapt and adjust to changing requirements at short notice. In simple words, the SDLC model had to be more “Agile.”
The linearity of the Waterfall Model and the iterative nature of the Spiral Model along with a few other concepts formed the basic framework for Agile.
What is Agile?
Agile is an iterative and incremental approach to software development with a baseline of adaptability for customer requirements. To adapt to changes, tasks had to be broken into smaller modules. Using smaller tasks with lesser iterations means that devs do not have to change large chunks of code if requirements alter or deviate.
Milestones are set to mark the completion of a development phase. A constant review process by customers helps shape the product to a desirable state. This method appealed to development organizations. Many started implementing it and found that it provided better results than previous methods.
Continuous Integration (CI) can be considered as a pillar of the Agile process. It is the process of developing software iteratively with small parts of code being integrated into the main code body repeatedly following all SDLC phases. The general approach is described below:
- Requirements are broken down into small tasks and assigned to team members
- The developer works on code and tests the logic of the feature on his system via Unit testing
- The code is committed regularly to a repository empowered with a Version Control System of some kind
- This kicks off a series of tests that can be either automated or manual. These tests aim to check the product health every time new code is added via Integration Testing. Integration Testing checks that new code does not break existing features
- The code is certified as ready for deployment once all tests pass
The above cycle continues until the desired product has been built. This also allows for easy feature enhancements after the initial version has been released.
Every company modifies and adds steps onto the above process based on their needs. Most companies work with three environments wherein the code is deployed and tested.
It begins with the Development Environment (DEV), which is a playground for developers to test their code.
After local unit testing, code is deployed onto the DEV, and a combined unit test suite is run.
The code is then deployed to the UAT/Integration environment. The frequency of this deployment varies based on the project. In this environment, code is put through integration testing to check for compatibility of newly developed features against existing code. This environment is also called a Sanity environment.
After integration tests are passed, the code is tagged and marked as deployment-ready.
Continuous Integration implements an iterative and incremental approach to software development. It reduces the cycle time of feature development while ensuring that the product is stable.
These days, CI is so widely used that CI and Agile are often considered synonymous, which is not entirely correct. But it signifies the effectiveness with which CI helps implement the Agile methodology.
Read More: Difference between CI/CD, Agile and DevOps
Implementation of a CI pipeline for Agile Teams
As discussed earlier, CI is the process of building and testing code repeatedly to get it deploy ready. Below is a sample CI process that many organizations follow:
- The developers develop the code and push it onto a central source code management system
- This code is built and deployed onto the DEV
- Tests are triggered to check if the code works as expected
- Regularly – nightly or weekly or fortnightly – this code is freshly constructed to include the latest code commit to the existing repository
- This build artifact is deployed onto the UAT or the Sanity environment, wherein the code is tested, as a whole, for its functionality
- Integration and regression test suites are run against the deployed code. Post that, the code is declared deploy-ready
These steps can be configured using multiple CI orchestration tools such as Jenkins, Bamboo, Teamcity, etc.
Let’s consider an example of how this configuration can be performed using Jenkins for Agile Teams.
Step 1: A Jenkins job can be created to build the code. The source code repo needs to be added in the SCM section as shown below:
Step 2: Additional build environment configurations can be done as required. Under the build section of the configuration, the build command can be issued. This can be done by using plugins or by executing shell commands directly. The image below uses Gradle to build the project:
Step 3: Configure the post-build section. Mails can be sent to notify the status of the job. Other builds can be triggered. Reports can be published. Jenkins offers numerous plugins for integrations with multiple tools. The image below depicts how to send a mail and also trigger another job once the current job has succeeded
Step 4: Configure the deploy job in a similar fashion. Tools like Ansible, Chef, Puppet are generally used by organizations to handle deployments to multiple servers. The image below shows how one can configure the build part of the job configuration to run an Ansible playbook:
Step 5: Like the build job, the deploy job can now trigger another job (Test Job is this case) upon its successful completion
Step 6: Once the code Is deployed onto the environment, a test job can be run to execute test cases against the deployed code. Another example of Gradle being used for testing:
Step 7: Once tests are run, reports are generated. There are multiple plugins available in Jenkins to publish reports from tools like TestNG framework, Cucumber, etc.
Similar pipelines can be created to trigger builds for UAT environments, perform the regression, and integrations testing. Most CI orchestration tools include multiple plugins and have options to create their plugins. Every project would have its own set of rules and requirements, and most CI tools allow devs to incorporate these requirements while using the CI pipeline.
CI helps the companies develop software that is customer-centric and simultaneously in line with healthy development practices. Bear in mind that the resultant code’s accuracy can only be guaranteed when it is tested on a real device cloud. BrowserStack’s cloud Selenium grid equips QAs with 2000+ real browsers and devices for automated testing so that every feature can be monitored in real-world circumstances. Additionally, the BrowserStack cloud offers integrations with a wide range of tools that enable CI and Agile-driven practices – Jenkins, TeamCity, Bamboo, Travis CI, and more.