CI/CD

Continuos Integration

Fast automated feedback on the correctness of your application every time there's a change to the code
integrate early and often
Everyone Commits to the Mainline Every Day

What you need

• Version Control - code, tests, database scripts, build and deployment scripts, anything you need to create, install, run, and test your application, no matter the size of your project
• An Automated Build—The automated build must be started from the command line, or a person or a computer must be able to run the build, test, and deployment process from the command line. Running through the command line is a best practice, no matter if you use an IDE or continuous integration tools; the idea is that these tools would use the same script you can run through your command line.
• Justifications
  • you must be able to run in an automated way so the build can be audited when things go wrong,
  • build scripts should be treated like your codebase, tested, and refactored constantly,
  • makes understanding, maintaining, and debugging the build more effortless, and allows better collaboration with the ops team
• Agreement of the Team — CI is a practice that requires commitment and discipline from your dev team
  • developers merge their code into the trunk daily.
  • developers break up extensive features into small, incremental changes
  • fix any change that breaks the build

Simple Process to Follow

...when starting to use CI Servers according to Jez Humble

1. Check to see if the build is already running. If so, wait for it to finish. If it fails, you'll need to work with the rest of the team to make it green before you check in
2. Once it has finished and the tests have passed, update the code in your development environment from this version in the version control repository to get any updates
3. Run the build script and tests on your development machine to make sure that everything still works correctly on your computer, or use your CI tool's personal build feature
4. If your local build passes, check your code into version control
5. Wait for your CI tool to run the build with your changes
6. If it fails, stop what you're doing and fix the problem immediately on your development machine - to step 3
7. If your build passes, rejoice and move on to your next task

Prerequisites to CI

According to Jez Humble

1. Check in regularly to Trunk or Mainline, at least a couple of times a day
   • makes your changes smaller and thus less likely to break the build
   • You have a recent known-good version of the software to revert to in case of mistake or wrong path
   • helps to be more disciplined about refactoring and stick to small changes that preserve behavior
   • ensure that changes altering a lot of files are less likely to conflict with other people's work
   • allows developers to be more explorative
   • force you to take regular breaks
   • ...
2. Comprehensive Automated Test Suite
   • without automated tests, passing a build is only to compile and assemble
   • It's essential to have some level of testing to provide confidence that your application is working
   • unit tests, component tests, and acceptance tests are kinds of tests we are interested in running from our CI
3. Keep the Build and Test Process Short If it takes too long
   • People will stop doing a complete build and running tests before checking in the code
   • The CI process will take so long that multiple commits will have taken place by the time you can rerun the build, so you won't know which check-in broke the build
   • People will check in less often.

Checking Into Trunk ...

• Use trunk-based development, although many projects use branches to manage large teams.
• It's impossible to do continuous integration while using branches, honestly, your code has not been integrated with that of other developers

Managing your development workspace

• Developers should be able to run the build, execute the automated tests, and deploy the application in an environment under their control
• Running the application locally should use the same automated process used in CI and testing environments, and ultimately in production
• For this, the use of configuration management for source code, test data, DB scripts, build scripts, and deployment scripts is needed, all of this in VCS, and should be the most recent version that passed all automated tests in your CI server
• configuration management of third-party dependencies, libraries, and components
• Make sure that automated tests, including smoke tests, can be run on developer machines

Essential Practices

According to Jez Humble

• Don't check in on a broken build.
• Always Run All Commit Tests Locally before committing, or Get Your CI Server to Do It for you
• Wait for Commit Tests to Pass before Moving On
• Never go home on a broken build
• Always Be Prepared to Revert to the Previous Revision
• Time-box Fixing before Reverting
• Don't Comment Out Failing Tests
• Take Responsibility for All Breakages That Result from Your Changes
• TDD

Continuous Delivery

Fast automated feedback on the production readiness of your application every time there's a change to code, infrastructure, or configuration.
Software is always deployable
Continuous Delivery makes it cheap and low-risk to release a new version of your software.

continuous delivery is ideal

• Software is always production-ready
• Deployments are reliable and commonplace
• Everyone can self-service deployments
• releases occur according to business needs, not operational constraints ### keys
• Architecture
  • Design for Testability
  • Design for Deployability
• Patterns and Practices
• Collaboration

  prerequisites

• configuration management
• automated tests
• continuos integration

Correlation with IT Performance

• Our code, app configuration, and system configurations are in a version control system.
• We get failure alerts from logging and monitoring systems
• VERY HARD TO ACHIEVE
  • Developers merge their code into the trunk daily
  • Developers break up extensive features into small, incremental changes
• When development and operational teams interact, the outcome is generally win/win

Puppet Labs - DevOps Report 2014

Continuous Delivery requires, as a pre reqs an intensive collaboration between different roles, minimizing the idea of silos. The team should be aware that delivering the software is everyone's responsibility. Developers, testers, UX, operations, and business people should work together and collaboratively through the delivery process. One practice is to have physical developers, testers, business, and operational people working together.

A simple value stream map for a product

Figure 1: A simple value stream map for a product - Jez Humble; David Farley - Continuous Delivery.

Deployment Pipeline - Release

Figure 2: Release - Jez Humble; David Farley - Continuous Delivery.

Production Readiness Confidence

Figure 3: Production Readiness Confidence - Jez Humble; David Farley - Continuous Delivery.

Deployment Pipeline - Continuous Delivery

Figure 4: Deployment Pipeline - Continuous Delivery - Jez Humble; David Farley - Continuous Delivery.