Continuous Integration, Continuous Testing, Continuous Deployment
In software development, integration is the process of combining individual software components into a single application. Continuous Integration (CI) is the practice of integrating new or changed code on a regular basis. Its purpose is to detect issues early in the development cycle. Instead of integrating code as part of a large, separate process toward the end of the implementation phase in the SDLC, CI aligns with Agile development by enforcing integration to occur frequently – at least once a day – thus enhancing agility and improving quality.
CI software such as Jenkins is used to automate the build, test and deployment processes. This encourages frequent code commits, frequent testing and frequent deployments which will help to detect defects early in development cycle.
Typically, code is stored in a repository handled by a Versioning Control System (VCS) such as Git or Subversion. As developers develop an application, they commit new or modified code to the repository . When the application is ready for QA testing, the code is pulled from the repository, a build is made, unit and integration tests are performed, and the application is deployed.
With CI software, all of these steps can be automated. CI software can grab the code from the repository, build the application, perform unit and integration tests then deploy the build to a test environment. Implementing automated test scripts into the CI pipeline allows QA analysts to focus on tests that must be performed manually.
Implementing a Continuous Integration system to automate the deployment process is beneficial for several reasons:
- Anyone on the team can run a build because the process is automated. Deploying an application is achieved with the click of a button.
- Events such as committing code can automatically trigger a build ensuring the current application is the most current.
- Automating the build process significantly mitigates build time resulting in faster deployments.
- Continuous Integration encourages frequent code commits because it alleviates manual processes.
- Frequent deployments allows defects to be discovered early in the development cycle.
- CI software can perform automated tests prior to deployment reducing the risk of errors.
- The application can be uploaded to a server to include TestFlight and web hosts.
- Allows resources such as developers to work on other tasks rather than deploying a build every time a new build is needed.
- Sends an alert when a build fails and notifies users when a build is complete.
One of most important features of Continuous Integration software is that it streamlines the build process. Automated tasks or jobs reduce the time and effort to build an application and deploy it. This encourages developers to frequently commit code because they don’t have to perform additional tasks such as manually running unit and integration tests every time code is pushed to the main repository. The following is a list of best practices to ensure CI efficiency:
- The build, test and deploy processes should be streamlined. A build should not take more than ten to fifteen minutes. If the CI server is taking too long to deploy a build, consider reducing non-essential tests as these can be performed during nightly jobs. Also consider re-factoring automated tests.
- Test with mock data rather than retrieving it from the database. Retrieving data from a database can use up a substantial amount of system resources causing builds to take longer than necessary. You can test data from the database during your nightly builds.
- If builds are triggered on commit, let the Version Control System send commit notifications to the CI server. Having the CI server frequently checking for updates add to the CI server’s workload.
- Breakdown large jobs into smaller ones. Large jobs take longer to run and can make it difficult to track down defects if the build fails.
- Maintain separate CI and build servers. While Continuous Integration software alone may not require large amounts of CPU or memory, running multiple jobs on large projects can tie up the server especially if you are building for multiple platforms. A single server might be sufficient for small projects but as the project expands and multiple projects are added in the future, a master CI server with slave build servers will be required.
- Build failures should be addressed sooner rather than later. It is easy to put off fixing defects when a build fails but as team members commit additional code, it will be more difficult to find the cause of the failure later on.
- Running large jobs nightly keeps resources free to perform normal builds during the day.
By Joey Bejasa, Consultant – Olenick & Associates, Chicago