In a continuous Integration process, code that has been checked into a source code repository can be automatically checked out, built, tested in a variety of ways, and published to a repository. For continuous integration to work, you need a CI server like Jenkins, which is able to monitor your source code repository for new changes and respond in configurable ways.
Take a Java application built using Maven as an example. On detecting code changes, your CI server could respond by executing a mvn clean install. In a typical Maven build configuration, it would execute a fresh set of unit tests as part of the build command. While the source code was being built, the server could execute any number of additional actions:
- Merge your feature branch back into your main or master branch once the committed code passed the unit test.
- Execute static code analysis, such as code coverage, code complexity, checks for common bugs, etc.
- Publish your build artifacts to a repository, such as Artifactory or Sonatype Nexus
- Deploy your application to an integration test environment
- Execute integration tests
- Deploy your application to a performance test environment
- Execute a load test against your application
- Deploy your application to a User Acceptance Testing Environment (UAT)
- Deploy your application to production
These steps are all types of activities that you might perform as part of a CI/CD process. CI typically encompasses the building-and-testing phases of the development lifecycle, whereas CD extends that process to deploying a build artifact to a server for testing. In some environments, CD goes all the way to production.
Continuous Integration is typically done using a tool like Jenkins, Bamboo, or TeamCity, which orchestrates your build steps into an integration pipeline. Jenkins is probably the most popular CI/CD product, and it pairs well with Docker, as you’ll learn in Part 2.
近期评论