Continuous integration

Automation that is used to perform builds of software and automate tests against that software.

Related

• Continuous deployment

Implementing continuous integration

In the early days of continuous integration (CI), it was common to have a batch job that ran daily and would perform automated builds to detect if there was code committed that would "break the build." As source control software became more mature, it provided the ability to drive this automation upon events, like merges with a certain branch, or other conditions. This automation has grown from merely performing a build script, to running tests, to running unit tests, to deploying in an environment where white and black box testing, or even load and performance testing, can be performed. If all tests are performed correctly (or simply the build, in its original version), the artifact is either placed into a location that it can be picked up for further testing (QA or UAT), or automatically deployed to that environment.

Implementation steps

• Create build automation (maven, ant, make, etc.) that creates artifacts in the official delivery location.
  • Schedule build with detection of errors.
  • Notify the people who committed the broken build code of the errors they introduced.
  • Integrate unit test automation (via Jenkins, Team City, etc.).
  • Add notifications of unit test failures.
  • Add deployment into an environment that can be used for further testing.
  • Add invocation of integration and white box and black box testing.
  • Add invocation of load tests.
  • Add invocation of performance tests.
  • Add invocation of resiliency tests.
  • Add other tests as identified.
  • Add deployment to pre-prod environments for acceptance.