Release Template [draft]

Owned by Jeremy Phelps
Last updated: Sept 22, 2017 by Brett Preston
2 min read

Template to set the workflow for any given release. The goal of the template here is to use well known and tested methods, simplify the process, and reduce any ambiguity that we can.  This helps to keep the focus on the product where it belongs by taking cognitive load out of managing releases.  This template should also not be seen as a final word; if someone has an objectively better method that improves this process then we should generally adopt that.

Some well known and tested methods we will adopt immediately

  1. Semantic Versioning http://semver.org/
       - Use of semver scheme for EdgeX individual services
       - Discuss further whether to version the named release (ie, Barcelona)
  2. Nexus Repositories (adopted from ONAP project)
    1. Snapshot repo: used for merged artifacts. After the committer has performed the code review (+2), has merged the code and the build is successful, the build artifact is within the Snapshot repo. It is expected to have multiple snapshots for a single repo per day. All artifacts have same version number.
    2. Staging repo: used for Release candidate. Once a day, a new clean build is automatically performed. All artifacts have same version number. The Staging artifact is used for the release testing (Testing beyond unit tests).
    3. Release repo: this is the place where the project team (or Linux Foundation Releng Team) stores the artifacts that are deemed stabled for being consumed by the other project teams. Each team decides when to release. It is not expected to get a new release every day. No TSC approval is required for getting a new release artifact.
  3. Dependencies on named release
       - Barcelona for example will contain a number of individual services that can be independently released.  We should manifest the particular services and corresponding version of that service that will be contained in Barcelona. 

General Development

  1. All general work goes against the master branch in each project.
  2. Individual Pull Requests will generate artifacts that are pushed to the Nexus snapshot respository.
  3. Daily builds will build master and push an artifact into the staging repository, these should be considered release candidates.

Release Process

  1. Branch Cutting

            - Project decides what will make it into the release branch.  This should not include new features but only bug/security fixes.  All new commits should be merged into master first and then we will cherry pick bug/security fixes.  This is "Code Freeze" .  It can happen some time after a release branch is but but makes sense to decided when to do the freeze and cut that branch at that time to minimize what we have to pick into the release branch.

            - Lock down permissions on the release branch to those who we wish to grant "Release Permissions".  

      2.  Generate or update named release manifest

             - This is the document which will enumerate each service and version that will be contained in a named release.

      3.  Individual service release

             - Each individual service can release separately if they wish.  If at any time a service is updated then we should also be sure to update the manifest.

....tbcont