Skip to content

Deployment Frequency

A basic engineering principle of software releases is to make small incremental changes often.
This is a win-win situation because it:

  • Encourages automation of the continuous delivery (CD) of your software, thus reducing manual mistakes in the delivery.
  • Encourages the automation of testing, thus reducing errors humans miss when doing routine, repetitive testing tasks.
  • Simplifies determining root-cause analysis when there is less code changing at a given release.
  • Allows VA customers, like the Veterans we serve, to see improvements sooner.

Guidance

  • Automate the delivery of the software to make releasing a trivial task.
  • Automate the testing of the software to make testing of the release trivial to humans.
  • Release small incremental improvements.
  • Release often, at least once every 2 weeks, or when a new feature or bug fix is ready.
  • Release critical bug fixes within 4 hours after it passes testing procedures.

How often is often enough?

VA encourages continuous integration and continuous delivery (CI/CD) of your API. We encourage weekly or every other week release schedules, or when the new feature or bug fix has passed testing, then release it.

Do not release code for the sake of releasing, but don't delay doing releases when a feature or fix is ready. The earlier a feature or fix is available, the earlier VA can reap the benefits.

This involves thinking about your API features differently and breaking down new features into small incremental changes versus large releases that generally require a more complex exit strategy and troubleshooting steps if things go wrong.

Bug fixes

Releasing bug fixes should be an immediate concern if it is a bug that is causing severe abnormal data behavior or the inability to use an application. Critical bug fixes should NOT wait for a normal release cadence and should be released within 4 hours after testing has passed for the patch.