Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

architecture agile project management deployments testing builds deploys learning
Getting software released to users is often a painful, risky, and time-consuming process. This groundbreaking new book sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users.
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Preface - xxi

Martin Fowler's and Kent Beck's team deployed software every night. Reducing the cyclce time between an idea and usable software.

Software release should be a fast repeatable process. Time from deciding you need to make a change to having it in production is cycle time.

Software delivers no value until its in the hands of its users. Majority of the cost associated with delivering successful software is incurred after the first release.

Continuous delivery comes from the agile manifesto: our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The Problem of Delivering Software - 3

Antipatterns

  • What are the antipatterns and how do they impact the SDLC?

    • Deploying software manually
    • Frequent corrections to the release process
    • Late nights and early mornings
    • Detailed process which could go wrong
    • Documentation must be maintained
    • Expensive to test

  • Deploying to a prod-like environment only after development is complete

    • Common for new bugs to be found
    • The longer the release cycle, the longer the development team is making incorrect assumptions before deployment occurs
    • High cost of coordination between departments when deploys go wrong

  • Manual config of prod envs

    • Different servers behaving differently
    • No rollback
    • Config should be in version

Build Pipeline

Commit stage (compile, unit tests, analysis) -> automated acceptance testing -> automatic capacity testing -> manual tests -> release

Good Patterns

  • Releases need to be automated and frequent

    • Shorten the feedback loop

  • Every change should trigger the feedback process

    • Syntax checking, build, process of creating the executable code
    • Unit test must pass
    • Quality metrics: test coverage
    • Functional tests
    • Non-functional tests
    • Exploratory testing and demo

Shorten the feedback loop

  • Optimize for human resource usage
  • Tests in commit stage are fast, comprehensive, can trigger a build failure, environment neutral
  • Later stage tests are slower and are candidates for paralellization, might fail and we might still release, run on environments similar to production.