Application Releases - Overview

A guide to how to best release applications, and what that all entails.

Releases vs Builds

Sometimes people think that releases and builds are the same thing. Often misused, here are the actual definitions:
 
Release
Defined as a planned set of changes to an application. Could be planned far in advance, or a single line change rushed to production in an emergency.
 
Build
Defined an attempt at implementing the requirements of a release. It is also a snapshot of the codebase that is tested before being “released” (deployed to production, given to the end user, etc)

Process

  1. Someone decides that certain changes are needed to an application
    • Documented in an issue tracking system, email, etc.
    • These changes constitute a Release
  2. A developer sees the changes needed, and modifies the application source code to implement the requirements.
  3. Once ready, the code is compiled, built, or otherwise assembled into a Build.
  4. This Build is then deployed into a non-production application environment such as "Integration" or "Staging"
  5. The build is tested in that environment
    • Smoke Test
    • In Depth Test
    • Not a "test of faith"
  6. After testing:
    • If the build meets the necessary testing criteria, and is verified as "ready", it is deployed ('released') to production.
    • If the build is inadequate (due to bugs, or the fact it was a prototype build), it is then rejected and the aforementioned build, deploy, and test scripts are run again.

Don't Break the Build

We don’t build applications, but we do run automated testing. If a build fails that, it is not ready to be released, and must be fixed immediately. The automated build should always be in a releasable state. Another branch.

Build Immutability and Completeness

The build that is deployed to staging should be exactly what’s deployed to ‘production’ … if necessary to recompile code after the first environment, the process should restart. Do not release builds in parts, as the new code you would deploy has not been tested with the old code you are not yet replacing.

There can only be one

We may create 10-20 builds, but only one will be released. Once a build has been deployed to production, the application has changed and will require a new release to be changed again, even if it’s a simple one-line fix. This “patch” release can follow different testing, but is still a new release.
 
e.g. Build 4 of Release 2.3 is 2.3.4

Release Planning and Changes

Plan on a date for the release to be done, at a specific time. Just make sure its set and you know the depth of what changes are in a specific release.
 
When changes are associated with builds (without going through the process) or when deployed piecemeal, you’re turning the program into a Jenga tower. When a build has been completed, has not been changed, and was tested and deployed, it is a full Jenga tower. Every change is taking a block out, or moving it around, creating instability. Enough instability and your tower (or your application) falls down.
 
Do not release applications on a Thursday or Friday. That is too close to the weekend, and since we are a public institution, we do not work on the weekends. While one of the web people will more than likely fix something broken on a Friday night, Saturday, or Sunday... they will not be happy.

Promotions

To do a proper release, the build gets promoted through several steps (development, staging/testing, and production). Each person who promotes the build through these steps is to make those changes in the bug tracking system so it is trackable. If the build fails at any point, you may not “demote” the build down, it becomes rejected.
 
Releases should follow the Git Flow methodology, tagging the release once the release/version branch is merged into master. We used to use timestamps (20140503) but now are moving towards semantic versioning.
 
Please notify saits-webteam@uwm.edu for all major application releases. In case the release goes bad, it can help to know what applications were recently updated. All releases should be in Git, so if this situation does occur we can roll back to that last working release.
 
Vanity URL Changes, documented with project
 
Notify end user of release, documented.



Keywords:best practices,application,releases,web   Doc ID:45202
Owner:Help Desk K.Group:UW-Milwaukee Help Desk
Created:2014-11-21 14:40 CSTUpdated:2019-01-02 14:38 CST
Sites:UW-Milwaukee Help Desk, UW-Milwaukee Student Affairs IT
Feedback:  0   0