Gitflow Workflow, Automated Builds, Integration & Deployment.

Working with teams can be quite challenging if there is no process in place to review and check code before it is merged, or more importantly to prevent ominous code from getting to production.

One important tool that can make collaboration with other developers hassle free, is a version control system. The most popular system at the time of writing this article, is Git.

Git is a system used for tracking changes in files and coordinating work on those files among multiple people; it is primarily used for source code management in development. It is free, open source and it handles everything from small to very large projects with speed and efficiency.

Over the years, I’ve seen developers use different workflows for Git. They usually include Basic, Feature Branch only, Feature Branch & Merge requests, Gitflow and Forking workflow. You can read up on these concepts here. But in pursuit of streamlining and automating our workflow from development to production, whilst working with other developers on your project, I would recommend using Gitflow.

Gitflow & How we can use it for automated integration & deployment.

So the idea is to have two major branches named Master & Dev which are linked to two environments: Staging (https://staging.exampleapi.com) & Production (https://exampleapi.com). Typically you should have your staging be an exact replica of your production environment.

Master Branch

The master branch is the production-ready version of our codebase which is automatically deployed to our production environment (https://exampleapi.com), with everything fully tested and checked. “Thou shall not touch this branch.”

This is how I feel, when this happens.

Dev Branch

The dev branch is where all feature branches are merged after pull requests have been thoroughly checked, fixed, and all tests are performed. Once all builds pass, this branch is deployed to the staging environment (https://staging.exampleapi.com) for QA & UATs.

Release Branch

Once it’s time for a release, a release branch should be created from the dev branch for final audit eg: cleanup & remove comments, versioning etc. This branch is tagged, and then merged to both master & dev branches.

You shouldn’t just merge into master from dev.

Access Control

All code changes to the dev branch should be made via a pull request, and to help prevent accidental direct pushes, you can use branch permissions. See images below for setting up branch permissions for both bitbucket.org & github.com. I’m sure most other revision platforms support this in one form or the other.

Bitbucket: Repo > Settings > Branch Permissions

Github: Settings > Branches > Protected Branches

Typical developer process

1. Developer has a task to do.
2. Developer branches dev, let’s call it feature/user-registration.
3. Developer works on feature/user-registration.
4. Developer writes their own unit tests for feature/user-registration.
5. Developer gets updates from dev when needed (by merging dev in). eg. “git pull origin dev”
6. Developer publishes feature/user-registration.
7. Developer does a final update from dev.
8. Developer makes sure their unit tests and all regression tests pass locally.
9. Developer pushes feature/user-registration
10. Developer makes sure their unit tests and all regression tests pass on build server.
11. Developer submits pull request to dev.
12. Pull request unit, integration and regression tests are run on build server.
13. Admin merges pull request into dev branch which is built and deployed to staging for QA & UAT.
14. Build server deletes remote feature/user-registration.
15. Developer deletes local feature/user-registration.
16. Goto step 1.

Some useful Git GUI clients: Smartgit, Sourcetree & Github Client

I hope this helps.