SuperGLUE-release

SuperGLUE Release Process

 NOTE:  
 As of 12 October 2018, the details on this page are outdated and do not reflect the still evolving release and deployment process for SuperGLUE |

This document describes the process for releasing components that are part of SuperGLUE.

Releasing or Publishing, as defined here, is simply versioning the software and merging it to the master branch of the component.

Deploying the software involves taking a published version and deploying it to some environment.

Component Versioning

The cornerstone of any release process is a sensible versioning scheme.

We use Semver and version components following the MAJOR.MINOR.PATCH system.

NOTE: The version talked about here is the component or code version NOT the product version. Product versions usually refer to deployed artifacts and many times include several components that make up a "product" or "feature".

Deploying

NOTE: The terms release and deploy are not the same: release allows a component (version) to be deployed, but itself is only code and the version of code, not where or how it is deployed. However, the terms are frequently used as synonyms, so for clarity, I'll avoid release and instead use the term publish.

When and where things are deployed is beyond the scope for this document. The only requirement to deploy a component is that it have a version (i.e., has been tested and merged to master).

See another wiki page with info on deploying a release.

Although we'll publish each component at the end of the sprint, we won't necessarily deploy it.

Deployment takes coordination with stakeholders and is beyond the scope of this document.

With approval of a planned deployment:

  1. File a ZenDesk ticket: https://infiniticg.zendesk.com/.
  2. Add to the ZenDesk ticket any link to release plan/commands.
  3. Infiniti will do the deployment.

Compoent Publish Frequency

At the end of every sprint, each component worked on during that sprint should be published and included in the "Sprint Report". The exception to this, is if a component doesn't pass QA and has jira ticket(s) that are still open or not closed. In this case, the component will not be published for the sprint and will roll over to the following sprint.

Jira Tracking

The Product Team will prioritize Jira tickets into each sprint. Tickets closed in the sprint have been developed, tested and documented as per the requirements defined in each ticket. Tickets not closed will roll over to the next sprint.

Jira shows the following information for tracking:

  1. Components : The git repos (code) affected by this ticket and who worked on them. TBD if this will use Jira Components or labels.
  2. Testing Status: The sprint the ticket was tested and closed in
  3. Documentation: Any release notes like dependencies, important changes and upgrade notes or other dialog related to the ticket can be seen in the Jira comments.

In addition, a "Sprint Report" Jira ticket will be created each sprint that holds summary information of the sprint to include:

  1. A list of the components modified that are being released.
  2. Each component's new version being released and merged to master.

Git Tracking

At the end of the sprint, we'll follow this process in Git:

  1. Merge master into develop, incorporating any hotfixes or patches. Resolve any conflicts in develop.

  2. Create a branch from develop for the new version (e.g., publish/MAJOR.MINOR.PATCH where MAJOR.MINOR.PATCH are defined in the pom.xml file and is the new version of the component).

  3. In the develop branch, edit the POM file's version to increment the MINOR field +1. This version will be used next time in step #2 above. This keeps the maven POM, Git repo, and Jira tickets all in sync with the specified version.

  4. Create a pull request to merge the publish branch into master. All devs working in the sprint can review.

  5. Add an annotated tag in Git with the version number (e.g., MAJOR.MINOR.PATCH). This tag will be what's used when we deploy the a published version to an environment.

    e.g., git tag -a 1.0.0 -m "Version 1.0.0"; git push --tags

  6. Once PR is approved, clicking the 'Merge' button in UI will merge the code to master.