HotFix Release Notes

Generated: Dec 10, 2018

Our hotfix process is used now on all ZenPacks. It requires that all maintenance revisions be made into a hotfix branch first, and then merged into both master and develop branches. This process requires that:

  • We use a 3 digit versioning system: Major.Minor.Revision, EX: 2.4.5
  • Develop branch already differs from master by a Major or Minor number

Note

You should be familiar with the details of Zenpack Release Notes if you have any questions concerning release details. In particular see the publishing notes at Publish the ZenPack Egg for post-egg creation steps.

Warning

Do not release a hotfix until QA has tested it from the Jenkins branch. Make sure you have included a link to the hotfix egg in the Jira fix commentary.

Preliminaries

First lets get all the version numbers in order. We’ll make bash variables for these.

  • Assume that develop is already incremented by a Major or Minor revision.

  • We use the following bash variables to reference our version numbers:

    export OLD_MASTER=2.2.0 export NEW_MASTER=2.2.1 export DEVELOP=2.3.0

Create the hotfix for the next patch release if it does not exit

You should, in general, always have a hotfix branch created that is incremented one Revision number. Once you finish this process, go ahead and make the new one as well with the appropriate number.

If you don’t already have one:

  1. git checkout master
  2. git pull
  3. git flow hotfix start ${NEW_MASTER}
  4. Edit setup.py: change VERSION ${OLD_MASTER} -> ${NEW_MASTER}
  5. git commit -am “Start ${NEW_MASTER} Hotfix: Version ${OLD_MASTER} -> ${NEW_MASTER}”
  6. git flow hotfix publish

Commit Changes to Hotfix:

Here follow a normal defect-fix process but adapted to be based on the hotfix. Once defects are made and hotfix is finished, hotfix will get merged into both master and develop branches. Details ensue:

  1. Make and commit changes needed in ${NEW_MASTER} hotfix

    1. git flow feature start ZPS-XXX hotfix/${NEW_MASTER}
    2. git flow feature publish
    3. work, work, commit & push
    4. make pull request from feature/ZPS-XXX to hotfix/${NEW_MASTER}
    5. Ensure small commits are squashed: :ref:`squashing_multiple_commits`
    6. review and merge
    7. git checkout hotfix/${NEW_MASTER}
    8. git pull
    9. repeat for all other existing issues

  2. Make sure to clean up all features branches that are merged: Clean Git Repo Branches

Finish hotfix when all fixes are made:

Now all hotfix changes are made and you are ready to merge into master (and implicitly, develop).

Warning

QA must test and approve the hotfix branch before you perform the folloing steps. Make sure you have approval before releasing.

  1. UNIT TESTS MUST PASS

  2. QA has tested and approved all defects, or you have higher approval

  3. Update Release section

  4. Update Changes section

  5. git commit -am “Finish ${NEW_MASTER} Hotfix: Version ${OLD_MASTER} -> ${NEW_MASTER}”

  6. git push

  7. git flow hotfix finish ${NEW_MASTER}

    • When asked for the tag, use:

      tag ${NEW_MASTER}

  8. On the entry page specify: tag ${NEW_MASTER}

  9. You will be automatically merged into develop

  10. More than likely you will see a merge conflict with setup.py on the develop branch
    1. fix the version in setup.py to match ${DEVELOP}
    2. git add setup.py
    3. git commit -a # Remove any conflict log entry, assuming you resolved it
    4. git push
    5. fix any other conflicts, commit, and push
    6. git flow hotfix finish ${NEW_MASTER}

  11. git push origin master develop

  12. git push –tags

Sanity Check

You should now be in the develop branch. Make sure all branch logs look like what you expect them to be. At the very least make sure that:

  • git status on all branches is clean

  • master logs have the hotfix changes

  • develop logs have the hotfix changes

  • The master and develop diff has no hotfix changes:

    git diff master..develop

Here are some other (undocumented) commands that may be useful:

  • git status
  • git log –all -p –graph
  • git diff master –stat
  • git checkout master
  • git log –graph
  • git checkout - # (returns to develop branch)

Build the Master on Jenkins

Now run a build of the master-ZenPacks.zenoss.X Jenkins job if it hasn’t already run it, and verify that the artifact has the new ${NEW_MASTER} version. See Publish the ZenPack Egg for further steps.

Workflow: Easy CLI Pull Requests on a Hotfix Branch

If you have hub from https://github.com/github/hub and hub is aliased to git, you can do the following in the CLI to make pull requests:

git flow hotfix start 1.2.3
git flow hotfix publish 1.2.3
git flow feature start ZPS-54321 hotfix/1.2.3
git flow feature publish ZPS-54321
# work work work commit & push
git pull-request -o -b hotfix/1.2.3

See this Document Without Variables

To see this document without the variables execute the following:

OLD_MASTER=2.2.0
NEW_MASTER=2.2.1
DEVELOP=2.3.0

wget -O /tmp/hotfix_release.txt \
   https://raw.githubusercontent.com/zenoss/ZenPackers/develop/hotfix_release.rst
sed "s/\${DEVELOP}/${DEVELOP}/g; \
     s/\${OLD_MASTER}/${OLD_MASTER}/g; \
     s/\${NEW_MASTER}/${NEW_MASTER}/g" \
     /tmp/hotfix_release.txt