Part 6 — Continuous Integration (CI)
On this page 4 headings
Why CI?
Deployment is important but time-consuming. Code written by many people must be integrated, tested sufficiently and deployed correctly to the live environment without bugs. Doing all of this by hand for every change is slow and error-prone.
Continuous integration is a way of automating the integration and deployment of software applications.
The CI process (7 steps)
Three systems are involved:
- Version Control System (VCS): stores the versions of the code.
- Continuous Integration server: automatically builds and tests the code.
- Staging / Deployment server: where the code is finally deployed.
The steps, exactly as on the slide:
- Developer commits code to the version control system (after writing and testing it locally).
- The CI server pulls the new code after each commit.
- The CI server builds and tests the code automatically, running unit and integration tests and checking for errors.
- If there are no errors, the CI server tells the staging/deployment server that the code is ready to deploy.
- The deployment server pulls the code from the version control system.
- The deployment server does one more round of building and testing, and deploys it.
- The deployment server notifies the CI server that deployment is complete.
Building, testing, integrating and deploying are all automated with scripts and the CI server.
Best practices for CI (7 practices)
Memorise these seven; the lecture summary lists exactly these.
1. Maintain a single source repository. Keep one mainline (master) branch, and most people should work on it most of the time. A few branches for trying new features or fixing bugs are fine.
2. Automate the build. A build involves compiling, copying and moving files, creating database schemas and so on. Build tools automate this once you write scripts with the correct configuration. The lecture’s examples: Ant and Gradle for Java, and “Builder” for Node.js.
3. Make the build self-testing. Create automated tests that check a large part of the code base. A simple command should run the whole test suite, and when a test fails, a notification should be sent to the developer responsible for that module.
4. Commit to the main branch every day. Before committing, developers write code, write tests, build, check for errors and check for conflict errors, which happen when someone else has already modified the same parts of the code. - Infrequent commits → more chances of conflict errors. - Frequent commits encourage developers to break their work into very small chunks.
5. Every commit should build the main branch on an integration server. The CI server monitors the repository. On every commit it pulls the new code, builds it, runs integration tests, and tells the committer whether everything works. If all tests pass, the build is successful. - Examples of CI servers: Jenkins and CruiseControl. (The lecture shows a CruiseControl dashboard listing recent builds, which passed or failed, how long they took and who made the changes.)
6. Fix broken builds immediately (a priority for developers): take the system back to the last-known good build so others are not affected, then fix the bug.
7. Automate deployment. Write scripts that deploy automatically, for example to the staging environment. This ensures that the latest code is always available in staging.
Reflection: what are the benefits of CI?
Think about benefits for end users, developers and the organisation before reading the lecture’s answer.
- Reduces deployment time. Building, testing and deploying are automated with scripts and the integration server, which minimises the steps needing human intervention.
- Avoids last-minute confusion and rush at release dates. Without CI, developers may not commit for weeks or months and then all commit just before a deadline, causing many conflicts. CI requires daily commits, so conflicts stay small.
- Beneficial to users. An updated copy of the software is always available on the staging server, so users can see an initial prototype, and the sales or management team can give a demo at any time.
- Beneficial to developers. Committing small pieces frequently pushes developers to write more efficient, modular code.
Drawback: the initial effort needed to set up the processes, set up the integration server and train people. In most cases the advantages far outweigh this.