Skip to content

Instantly share code, notes, and snippets.

@mrblueblue

mrblueblue/release.md

Last active June 1, 2017 20:44
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save mrblueblue/f6340631e82ca9f2f3d1e5d18c20281f to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save mrblueblue/f6340631e82ca9f2f3d1e5d18c20281f to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. mrblueblue revised this gist Jun 1, 2017. No changes.
  2. mrblueblue revised this gist Jun 1, 2017. 1 changed file with 12 additions and 6 deletions.
    18 changes: 12 additions & 6 deletions release.md
    View file
    Original file line number Diff line number Diff line change
    @@ -21,21 +21,25 @@

    #### Step 1: Release Branch

    After all features and fixes that we want to be part of the release have been merged into `develop`, we branch off and create a new release branch. This can be named anything.
    Once the `develop` branch contains all the necessary features and fixes, we branch off and create a new "release" branch. This branch can be named anything.

    To create a release candidate, we "upload" this branch to the [Jenkins job](https://jenkins.mapd.com/job/mapd-immerse-release) called `mapd-immerse-release`. After it builds and all checks pass, we are ready to put the rc on the pre-production `minos` server (this is something Michael or Andrew will do).
    To create a release candidate, we "upload" this branch to the [Jenkins job](https://jenkins.mapd.com/job/mapd-immerse-release) called `mapd-immerse-release`. After it builds and all checks pass, we are ready to put the release candidate on the pre-production [`minos`](http://minos.mapd.com:8000/) server (this is something Michael or Andrew will do).

    #### Step 2: Releasing

    After the rc has been uploaded to [minos](http://minos.mapd.com:8000/) the release captain and QA will verify the stability of the application. Usually this takes the form of going over the "release checks"
    After the release candidate has been uploaded to [`minos`](http://minos.mapd.com:8000/) the release captain and QA will verify the stability of the application. Usually this takes the form of going over the "release checks" manually and/or using automated scripts to do the work.

    If
    During this check process, new bugs might be found with the release candidate. When this happens, the release captain works with QA to triage the issue, either designating it as a regular bug or as a "release blocker" if it is serious enough. Fixes to release blockers are merged into the release branch.

    Once
    Once all checks have been done and no problems have been found, then the release is ready to be certified and made official.

    #### Step 3: Merging Back

    Once the rc has been officially certified and released we begin the process of merging back the release back back to master and from master back to develop.
    Once the release candidate has been officially certified and released we begin the process of merging back the release back back to master and from master back to develop.

    To merge the release branch into master, the release captain creates a PR. Once that is merged into master, another PR is made to merge master into develop.

    After all branches have been updated, we can now tag the master branch like so:

    ```
    git tag $VERSION_TAG
    @@ -44,7 +48,9 @@ git push origin $VERSION_TAG

    #### Following Up

    Sometimes bugs will be found in the release that need to be "hotfixed" or "patched." The hotfix process largely follows the same steps as above, the key difference being the git workflow.

    To make a hotfix, we branch off the `master`, creating a hotfix branch. This branch serves virtually the same function as a release branch. Once the hotfix is certified, we cherry-pick the changes to `master` and `develop`.

    ### Tips
    * DO keep in contact and communicate with QA and the release channel. It always better to give more information and pre-emptively notify people on the status of the release.
  3. mrblueblue revised this gist Jun 1, 2017. 1 changed file with 26 additions and 11 deletions.
    37 changes: 26 additions & 11 deletions release.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@

    ##### Release Captain

    > the team member responsible for cutting a rel
    > the team member responsible for managing the release branch and communicating with QA and management about the status of the current release
    ##### Release

    @@ -14,24 +14,39 @@

    > a snapshot of MapD Core and Immerse that is meant to be "released"
    ### General Outline
    ### General Steps
    1. Create a release branch from develop
    3. Check for release stability
    3. Check for release stability and then release
    4. Merge release branch into master/develop

    ### General Guidelines
    * DO keep in contact and communicate with QA and the release channel. It always better to give more information and pre-emptively notify people on the status of the release.
    * DO be aware of team bandwidth. Sometimes issues will need to be fixed to unblock a release. Be aware of what other team members are working on and always
    * DO triage newly found issues. The `release blocker` tab carries a lot of weight, so make sure that the issue is critical enough to warrant the label

    #### Step 1: Release Branch

    After all features and fixes that we want to be part of the release have been merged into `develop`, we branch off and create a new release branch. This can be named anything.

    To create a release candidate, we "upload" this branch to the [Jenkins job](https://jenkins.mapd.com/job/mapd-immerse-release) called `mapd-immerse-release`. After it builds and all checks pass, we are ready to put the rc on the pre-production `minos` server (this is something Michael or Andrew will do).

    #### Step 2: Release Checks
    #### Step 2: Releasing

    After the rc has been uploaded to [minos](http://minos.mapd.com:8000/) the release captain and QA will verify the stability of the application. Usually this takes the form of going over the "release checks"

    If

    Once

    #### Step 3: Merging Back

    In this step
    Once the rc has been officially certified and released we begin the process of merging back the release back back to master and from master back to develop.

    #### Step 3: Merging Back
    ```
    git tag $VERSION_TAG
    git push origin $VERSION_TAG
    ```

    #### Following Up



    ### Tips
    * DO keep in contact and communicate with QA and the release channel. It always better to give more information and pre-emptively notify people on the status of the release.
    * DO be aware of team bandwidth. Sometimes issues will need to be fixed to unblock a release. Be aware of what other team members are working on and always
    * DO triage newly found issues. The `release blocker` tab carries a lot of weight, so make sure that the issue is critical enough to warrant the label
  4. mrblueblue revised this gist May 31, 2017. 1 changed file with 8 additions and 1 deletion.
    9 changes: 8 additions & 1 deletion release.md
    View file
    Original file line number Diff line number Diff line change
    @@ -19,12 +19,19 @@
    3. Check for release stability
    4. Merge release branch into master/develop

    ### General Guidelines
    * DO keep in contact and communicate with QA and the release channel. It always better to give more information and pre-emptively notify people on the status of the release.
    * DO be aware of team bandwidth. Sometimes issues will need to be fixed to unblock a release. Be aware of what other team members are working on and always
    * DO triage newly found issues. The `release blocker` tab carries a lot of weight, so make sure that the issue is critical enough to warrant the label

    #### Step 1: Release Branch

    After all features and fixes that we want to be part of the release have been merged into `develop`, we branch off and create a new release branch. This can be named anything.

    We then "upload" this branch to the [Jenkins job](https://jenkins.mapd.com/job/mapd-immerse-release) called `mapd-immerse-release`. After it builds and all checks pass, then we are ready
    To create a release candidate, we "upload" this branch to the [Jenkins job](https://jenkins.mapd.com/job/mapd-immerse-release) called `mapd-immerse-release`. After it builds and all checks pass, we are ready to put the rc on the pre-production `minos` server (this is something Michael or Andrew will do).

    #### Step 2: Release Checks

    In this step

    #### Step 3: Merging Back
  5. mrblueblue created this gist May 31, 2017.
    30 changes: 30 additions & 0 deletions release.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,30 @@
    ### Releasing

    ### Terms

    ##### Release Captain

    > the team member responsible for cutting a rel
    ##### Release

    > a stable snapshot of MapD Core and Immerse that contains all the desired features to be "released"
    ##### Release Candidate (RC)

    > a snapshot of MapD Core and Immerse that is meant to be "released"
    ### General Outline
    1. Create a release branch from develop
    3. Check for release stability
    4. Merge release branch into master/develop

    #### Step 1: Release Branch

    After all features and fixes that we want to be part of the release have been merged into `develop`, we branch off and create a new release branch. This can be named anything.

    We then "upload" this branch to the [Jenkins job](https://jenkins.mapd.com/job/mapd-immerse-release) called `mapd-immerse-release`. After it builds and all checks pass, then we are ready

    #### Step 2: Release Checks

    #### Step 3: Merging Back