Skip to content

Latest commit

 

History

History
71 lines (51 loc) · 3.95 KB

project-conventions.md

File metadata and controls

71 lines (51 loc) · 3.95 KB
Raw

Project Conventions

Code styleguide

This project’s code formatting is enforced with Prettier for supported languages. Make sure to have Prettier integrated with your editor to auto-format when saving files, or to manually run it before committing (npm run format).

Python code is formatted with Black. Run automatic fomatting with black . in the VM or on your host machine.

These style conventions are enforced through CI pipelines.

Git branching model

The following resources are for internal project developers. Open source contributors please refer to the contribution guidelines.

We follow a loose version of the Git flow branching model. A summary would be "like git-flow, but 'develop' is called 'release'".

  • Make pull requests against: release
  • The release prep branch is: release
  • Start new features by branching from: release
  • Start bug fixes by branching from: master
  • The client QA branch is: staging
  • The internal QA branch is: staging
  • Do not treat the following branches as merge sources: staging

To create a new feature or bugfix, use the following process.

  1. Make changes on a new branch, including a broad category and the ticket number if relevant e.g. feature/123-extra-squiggles, fix/newsletter-signup.
  2. Summarise your changes in CHANGELOG.md. Sort lines by ticket number (this makes merge and deployment diffs simpler).
  3. Push your branch to the remote.
  4. Make merge requests at https://git.torchbox.com/buckinghamshire-council/bc/merge_requests/new, setting the 'Source branch' to your feature branch and the 'Target branch' to release. Select 'Compare branches and continue'.
  5. Edit details as necessary. Use the MR templates configured in GitLab, and the checkboxes therein and project labels to illustrate the current status of the MR.

If you need to preview work on staging, this can be merged and deployed manually without making a merge request. You can still make the merge request as above, but add a note to say that this is on staging, and not yet ready to be merged to release.

NB The MR templates are in version control at .gitlab/merge_request_templates/.

Deployment Cycle

Versioned releases

The version number is of the form MAJOR.PATCH. Planned releases which add features increase the major version number. Bug fix releases increase the patch number.

  1. Make merge requests to the branch release.
  2. Add a heading # x.x (yyyy-mm-dd) to CHANGELOG.md, detailing what is in this release.
  3. Add a comparison link below the x.x heading (see other releases for syntax; note that this will not work until the release is tagged, below)
  4. Merge release to master.
  5. Deploy to Production and Content Prep (see continuous deployment documentation).
  6. Tag the merge commit
    1. git tag x.x
    2. git push --tags

Tidy up: merge master to staging, and if necessary back to release. Check the repository graph looks sensible (https://git.torchbox.com/buckinghamshire-council/bc/-/network/master).

Deploying bug fixes

Urgent bug fixes should be made against the latest-deployed release, i.e. x.x.

  1. Pull master.
  2. Create the bug fix branch, e.g. hotfix/mend-squiggles.
    1. In CHANGELOG.md, add a new section to x.(x+1) (yyyy-mm-dd) where the date is the release date.
    2. Add a comparison link below the x.x heading (see other releases for syntax; note that this will not work until the release is tagged, below)
  3. If it needs client approval, or to be user-tested, deploy to staging.
  4. Make a merge request from hotfix/mend-squiggles to master.
  5. Once the change is approved, accept the merge request, and deploy to Production and Content Prep
  6. Tag the merge commit
    1. git tag x.(x+1)
    2. git push --tags
  7. Merge master into release.