Skip to content
Architect's Handbook Wiki

DevOps practices

Practice · Chapter 13

DevOps practices

Section titled “DevOps practices”

A typical DevOps release cycle runs through: Development → Integration → Build & unit testing → Delivery to staging → Acceptance testing → Deployment to production. The three central practices are continuous integration (CI), continuous delivery (CD), and continuous deployment.

Continuous integration (CI)

Section titled “Continuous integration (CI)”
  • Developers merge changes into a shared version control repository as often as possible; version control is a necessity.
  • Frequent, regular commits reduce conflicting changes and make conflicts easier to resolve.
  • Covers development, integration (checking in changes), and an automated build with automated unit testing.
  • Delivery to staging afterward may be counted as CI or as the first step of continuous delivery.

Automated builds

Section titled “Automated builds”
  • Two CI essentials: build all commits, and make the build process automated (triggered on check-in).
  • A build converts source, files, and assets into final usable form. May include: dependency checking, compiling, packaging (JAR/ZIP), creating installers, creating/updating DB schema, running data-change scripts, running automated tests.
  • Automation removes manual variation and ensures consistency; builds should be reasonably fast (e.g. under ~20 minutes) to keep CI feasible.

Software versioning

Section titled “Software versioning”
  • Assigning a unique number/name to a build. A formal convention communicates the software’s state to internal and external parties and enables dependency management.
  • Semantic Versioning (SemVer): MAJOR.MINOR.PATCH (e.g. 1.5.2).
    • MAJOR — breaking changes.
    • MINOR — backward-compatible additions/changes.
    • PATCH — backward-compatible bug fixes.
    • Initial development typically starts at 0.1.0.
    • A hyphen + identifiers marks a pre-release (e.g. 1.5.2-beta), which is lower precedence and may be unstable.

Automated testing

Section titled “Automated testing”
  • Run automated tests as part of the build to catch defects since the last good build.
  • CI detects errors sooner; changesets are smaller and fewer, so issues are easier to isolate.
  • Technically possible without automated tests, but tests raise quality and reduce manual QA effort.
  • Build results (esp. build breaks) must be visible so the right developer can fix quickly; CI limits how much work is lost on a revert.
  • Caveat: writing a complete, high-quality test suite takes real effort, or defects slip through undetected.

Continuous delivery (CD)

Section titled “Continuous delivery (CD)”
  • Ability to release changes to users quickly, sustainably, and repeatably, in short cycles (lowers risk, cost, effort).
  • Requires automated testing and automated builds.
  • Goal: software is always in a deployable state. Includes everything in CI plus automated delivery to staging, automated acceptance testing, and deployment to production.
  • The final deployment to production is manual (release on whatever cadence the org chooses) — but earlier/more frequent releases increase the benefits (faster feedback, smaller, easier-to-troubleshoot changes).
  • Smoke test after production deployment: quick check that crucial functionality works; not exhaustive, but confirms the deployment is stable.

Continuous deployment

Section titled “Continuous deployment”
  • Takes CD one step further by automating the deployment to production as well — the fastest, end-to-end automated path to production.
  • Ideal DevOps goal when the business/application permit it.
  • Not always appropriate: some organizations keep production deployment manual for business reasons. Architects and decision makers decide whether it fits.
Section titled “Related”

Citations

Section titled “Citations”
  • Software Architect’s Handbook (Packt, 2018), Ch.13 “DevOps practices”, pp. 1008-1015.