How We Supercharged GitLab with a Custom GitHub Flow

I just had a call with a client’s developer. They wanted to take over the development of a tool we’ve built for them.

They asked me if they should stick with our branching setup or not.

We use githubflow.github.io and it’s great.

Here’s a quick explanation. GitHub Flow is a lightweight, branch-based workflow designed to streamline and simplify collaboration on software development projects. GitHub Flow provides a simpler, more flexible approach:

Continuous Deployment: Facilitates frequent deployments, allowing quick responses to issues and feature requests.
Unified Process: No distinction between hotfixes and small features; everything follows the same simple process.

Our Modified GitHub Flow

To enhance our deployment process, we’ve made some modifications to the standard GitHub Flow. Here’s how our workflow operates:

Master Branch Anything in the master branch is deployable. This branch represents the production-ready state of the codebase.
Feature Branches For any new work, we create descriptively named feature branches off master. This helps in tracking and understanding the purpose of each branch.
Preview Deploy Branch Before merging feature branches into master, we first merge them into a preview deploy branch. This step allows us to deploy and test the new features in a staging environment before they go live.
Staging Deployment Our .gitlab-ci.yml file for staging deployment looks like this:

deploy_preview:
  <<: *deploy_script
  stage: deploy
  environment: preview
  variables:
    REMOTE_HOSTS: ...
  dependencies:
    - build
  only:
    - deploy

This configuration ensures that all feature branches are first deployed to a preview environment, allowing us to thoroughly test them.

Tags and Production Deployment

We use tags on branches to manage our production deployments. When preparing for production, we test the code thoroughly and always check the commit hash to identify the version being tested. Once approved, we set a tag in the preview deploy branch and then manually trigger the deployment.

Our production deployment configuration in .gitlab-ci.yml looks like this:

deploy_preview:
  <<: *deploy_script
  stage: deploy
  environment: preview
  variables:
    REMOTE_HOSTS: ...
  dependencies:
    - build
  only:
    - tags
  when: manual

This extra manual confirmation step before production deployment ensures that everything is thoroughly reviewed and approved.

For a more practical understanding , be sure to watch the full video. It’s packed with insights that will help you master github flow. Don’t miss out!