Version control

This process was written a long time ago and is due for review. It's been left here in case it's useful to you, but a different approach may apply for your projects.

Process for deployment isn't standardised across our client base so you will need to check the exact steps with a lead developer. If you are unsure then don't push any code to the master branch until you have investigated.

We use bitbucket pipelines to automate as much as possible in the deployment process, for example:

• Code linting

• Automated testing

• Deployment to hosting environments

git-flow are a set of git extensions to provide high-level repository operations for Vincent Driessen's branching model.

To install:

$ brew install git-flow-avh

Start using git-flow by initialising it inside an existing git repository:

$ git flow init

You’ll be asked a few questions, and it is okay to choose the default options (unless told otherwise)

Development of new features starting from the develop branch.

Start developing a new feature

To start a new feature branch:

$ git flow feature start PROJ-NUM-branch-name

This action creates a new feature branch based on develop and switches to it

When creating a new branch to work on a ticket assigned to yourself in JIRA, you should start the branch name with the ticket number, i.e NAM-123. This will be on your ticket

Once finished with work your work, push your code up with a helpful commit message containing the ticket number

$ git commit -m”ABC-123: Create new map component”

When your work is pushed up, create a new pull request that will merge into develop, and assign to a team member to review. Once accepted, you will merge your branch into develop

Consider Squashing your commits for work that has a lot of commits that aren’t necessarily important to look back uponGit Flow

We use the system of git flow for managing branches on all of our projects. You can read more about git flow here. We also strongly encourage you to use the git flow commands to help with correctly managing the branching and merging processes.

Releasing

Once code in the develop branch has been approved for release by a client you can merge it back to the master branch. To start a release, use this command:

$ git flow release start tagname

It creates a release branch created from the 'develop' branch. See "tag versions" below on how to choose the correct tag name. You may now wish to publish the release branch for testing in a staging environment. Once the release is ready (or immediately if the release was already signed off) you should run

$ git flow release finish --push tagname

to merge the release branch back to master and develop and push a new tag.

Finishing a release is one of the big steps in git branching. It performs several actions:

• Merges the release branch back into 'master'

• Tags the release with its name

• Back-merges the release into 'develop'

• Removes the release branch

Hotfixing

Hotfixes arise from the necessity to act immediately upon an undesired state of a live production version

A hotfix may be branched off from the corresponding tag on the master branch that marks the production version.

$ git flow hotfix start tagname

You will need to specify a tagname, see "tag versions" below on how to choose the correct tag name.

The version argument hereby marks the new hotfix release name. Optionally you can specify a basename to start from.

Finish a hotfix

By finishing a hotfix it gets merged back into develop and master. Additionally the master merge is tagged with the hotfix version.

git flow hotfix finish -m”” --push tagname

Tag versions

Whenever we're tagging code for a release we use the following pattern: a.b.c. Where:

• a is always 1

• b is the release number

• c is the hotfix number

When creating a new hotfix you'll need to increase c by 1.

When creating a new release you'll need to increase b by 1 and set c back to 0.

You can find the most recent tag numbers on a project by running git tag | tailFor example:

$ git tag | tail
1.7.0
1.7.1
1.7.2
1.7.3
1.7.4
1.7.5

From list list, the next release should be 1.8.0 and the next hotfix should be 1.7.6

UAT

UAT branches are helpful for when clients want rapid deployment, can increase complexity. To create a UAT branch, create a feature branch as normal and then push the feature branch up for PR as usual. Once the PR has been approved, rather than merge in develop, you will create a new branch called UAT, branched from develop

Any changes of a feature, the changes are only pushed into the feature branch and then that feature branch is merged back into the UAT branch,

When using this model UAT usually points to the dev environment, develop points to stage, and then a tag will get deployed to production

When you’re not using a UAT develop > dev environment, master goes to stage and tagged to live

Deployment

Process for deployment isn't standardised across our client base so you will need to check the exact steps with a lead developer.

If you are unsure then don't push any code to the master branch until you have investigated.

We use bitbucket pipelines to automate as much as possible in the deployment process, for example:

• Code linting

• Automated testing

• Deployment to hosting environments

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.