Skip to content

Latest commit

 

History

History
107 lines (84 loc) · 5.97 KB

development-processes-checklists.md

File metadata and controls

107 lines (84 loc) · 5.97 KB

Development Processes Checklists

Processes of Each Sprint

Note: In order to complete all of the steps below a user will need:

  • to be a member of the openscope-admins team within the openScope team on GitHub
  • have access to the openScope pipeline on Heroku

Each sprint is considered to progress through these three phases. Further details about each phase can be found in the sections below. The development phase lasts the majority of the sprint, with the first two days of the sprint being reserved to the initialization phase, and the last three being reserved to the testing phase.

  1. Initialization Phase (first two days)
  2. Development Phase
  3. Testing Phase (last three days)

The checklists below must be completed at the beginning of the phase for which they are named.

Note: Except on the first merge of a hotfix/bugfix/feature branch, please always use git merge branchName with up-to-date local branches, and not git pull origin branchName, as the latter forces a non-FF merge, which is often undesirable.

In total, each sprint cycle will include the following actions in the following order:

  1. Sprint Closeout Procedure
  2. Before Development Phase Checklist
  3. Proceed with development in accordance with the Development Procedures
  4. Testing Phase Checklist
  5. Release Procedure

Sprint Closeout Procedure

  1. Clean up sprint board and milestone.
    • Ensure they only contain resolved items.
    • Move any items that have not been resolved.
  2. Close sprint (Zube) and milestone (GitHub).

Before Development Phase Checklist

  1. Checkout develop.
  2. Attempt to merge master into develop with git merge master.
    • By design, develop should contain no changes, resulting in git replying Already up-to-date.
  3. If changes were merged, push to origin.
  4. Delete previous release branch, and leave only the latest release branch.

Development Procedures

  1. Merging feature and bugfix branches:
    • Use non-FF merges into develop via "the green button" or either of the below commands:
      • git pull origin feature/### (merges latest version of upstream branch)
      • git merge --no-ff feature/### (merges local version of branch)
    • Set/amend the merge commit's message to take the following form:
      • Include summary of Merge [category]/### (#[PRNumber]).
      • Include description that very briefly explains the purpose of that branch.
  2. Merging hotfix branches:
    • Use non-FF merges into master via "the green button" or either of the below commands:
      • git pull origin hotfix/### (merges latest version of upstream branch)
      • git merge --no-ff hotfix/### (merges local version of branch)
    • Set/amend the merge commit's message to take the following form:
      • Include summary of Merge hotfix/### (#[PRNumber]).
      • Include description that very briefly explains the purpose of that branch.
    • Merge master into develop with git merge master.
      • Note that this merge will have conflicts due to the different version numbers and CHANGELOG. Resolve and allow the merge commit.
      • Include summary of Merge hotfix/### (#[PRNumber]) from master.
      • Include the same description in the second line.

Testing Phase Checklist

At least three days prior to the end of the sprint, we will create a release branch that represents the state of the simulator after the current sprint's work. This release branch is temporary and has a short lifespan. It exists solely to provide a testing environment segregated from both the development and production versions of the app.

  1. Checkout develop.
  2. Create new branch release/#.#.# from develop.
  3. Open a pull request for release/#.#.# into master.
    • Include a title of the version number, eg 'v#.#.#'.
    • Include a description of copied from the CHANGELOG.
  4. On Heroku, change staging app to point to this new release branch.
  5. Broadcast publishing of testing app and seek feedback and/or bug reports. Any bugs should be reported to the #bugs room in slack and will be triaged from there.
  6. Merge any applicable bugfix branches into release/#.#.#.
    • Include summary of Merge bugfix/ (#[PRNumber])
    • Then on develop, run git merge release/#.#.# (results in a FF) and push.

Only bugfix branches may be merged (to release/#.#.# --> develop) during this phase.

Release Procedure

  1. Checkout release/#.#.#.
  2. Commit and push to origin the following finalizations to the release branch.
    • Set new release's version number in package.json.
    • Clean up changelog file.
      • Remove the extra empty lines in each section.
      • Update current sprint's version number and release date.
    • Use commit message ARCH - Finalize CHANGELOG and set version number for v#.#.# release
  3. Merge release/#.#.# into master by accepting the existing pull request for the release/#.#.# branch.
    • Include summary of Deploy v#.#.# (#[PRNumber]).
  4. Checkout master.
  5. Create and push a new version tag.
    • git tag v#.#.# and git push origin v#.#.#
  6. On the repository's tags page, find the newly created tag and add release notes.
    • Include title of the version number, eg v#.#.#.
    • Include a description copied from the CHANGELOG.
  7. On Heroku, change staging app to maintenance mode.
  8. Checkout develop.
  9. Merge master into develop with git merge master (results in a FF).
  10. Commit with ARCH - Prepare CHANGELOG and set beta version for upcoming sprint and push.
    • Set version number to planned number for this sprint, plus -BETA, eg v#.#.#-BETA.
    • Prepare changelog for next sprint by adding sections and whitespace.

Only hotfix branches may be merged (to master --> develop) during the initialization phase. Always add tags and release notes with each hotfix.