Continuous Integration in Agile

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 successfully accommodates and implements these changes is bound to create better software.

This is precisely what the Agile development methodology does. This article will focus on a 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. The blueprint 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 – linearly moving through requirements gathering, design, implementation, testing, and maintenance. 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. All the SDLC stages would be followed if changes were recommended 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 software development companies. Traditional SDLCs were inadequate, as they often took too much to meet 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. Simply put, 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 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 customer review process helps shape the product to a desirable state. This method appealed to development organizations. Many started implementing it and found it provided better results than previous methods.

Continuous Integration

Continuous Integration (CI) can be considered as a pillar of the Agile process. It is 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’s health whenever new code is added via Integration Testing.
• 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 release.

Every company modifies and adds steps to the above process based on their needs. Most companies work with three environments wherein the code is deployed and tested.

1. It begins with the Development Environment (DEV), a playground for developers to test their code.
2. After local unit testing, code is deployed onto the DEV, and a combined unit test suite is run.
3. 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 tested through integration to check for compatibility of newly developed features against existing code. This environment is also called a Sanity environment.
4. After integration tests are passed, the code is tagged and marked as deployment-ready.
5. Continuous Integration implements an iterative and incremental approach to software development. It reduces the feature development cycle time while ensuring the product is stable.
6. CI is so widely used these days that CI and Agile are often considered synonymous, which is incorrect. But it signifies the effectiveness with which CI helps implement the Agile methodology.

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:

1. The developers develop the code and push it onto a central source code management system
2. This code is built and deployed onto the DEV
3. Tests are triggered to check if the code works as expected
4. Regularly – nightly or weekly or fortnightly – this code is freshly constructed to include the latest code commit to the existing repository.
5. This build artifact is deployed onto the UAT or the Sanity environment, wherein the code is tested, as a whole, for its functionality.
6. 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: Similarly configure the deploy job. Tools like Ansible, Chef, and 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. Multiple plugins are available in Jenkins to publish reports from tools like TestNG framework, Cucumber, etc.

Similar pipelines can trigger builds for UAT environments and perform regression and integration testing. Most CI orchestration tools include multiple plugins and have options to create their plugins. Every project has its rules and requirements, and most CI tools allow devs to incorporate these requirements while using the CI pipeline.

Continuous integration in Agile helps companies develop customer-centric software that aligns with healthy development practices. Remember that the resultant code’s accuracy can only be guaranteed when tested on a real device cloud.

• BrowserStack’s cloud Selenium grid equips QAs with 3000+ 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.