Development and Production Environments with GitHub flow

Question

At work, we're now using GitHub, and with that GitHub flow. My understanding of GitHub flow is that there is a master branch and feature branches. Unlike git flow, there is no develop branch.

This works quite well on projects that we've done, and simplifies things.

However, for our products, we have a development and production environment. For the production environment, we use the master branch, whereas for the development environment we're not sure how to do it?

The only idea I can think of is:

1. When a branch is merged with master, redeploy master using GitHub actions.
2. When another branch is pushed, set up a GitHub action so that any other branch (other than master) is deployed to this environment.

Currently, for projects that require a development environment, we're essentially using git flow (features -> develop -> master).

Do you think my idea is sensible, and if not what would you recommend?

Edit:

Just to clarify, I'm asking the best way to implement development with GitHub Flow and not git flow.

Answer 1

In my experience, GitHub Flow with multiple environments works like this. Merging to master does not automatically deploy to production. Instead, merging to master creates a build artifact that is able to be promoted through environments using ChatOps tooling.

For example, pushing to master creates a build artifact named something like my-service-47cbd6c, which is a combination of the service name and the short commit hash. This is pushed to an artifact repository of some kind. The artifact can then be deployed to various environments using tooling such as ChatOps style slash commands to trigger the deloy. This tooling could also have checks to make sure test environments are not skipped, for example. Finally, the artifact is promoted to production.

So for your use case with GitHub Actions, what I would suggest is this:

1. Pushing to master creates the build artifact and automatically deploys it to the development environment.
2. Test in development
3. Promote the artifact by deploying to production using a slash command. The action slash-command-dispatch would help you with this.

Answer 2

You might also consider the notion of environments (as illustrated here)

Recently (Feb. 2021), you can:

##Limit which branches can deploy to an environment

You can now limit which branches can deploy to an environment using Environment protection rules.

When a job tries to deploy to an environment with Deployment branches configured Actions will check the value of github.ref against the configuration and if it does not match the job will fail and the run will stop.

The Deployment branches rule can be configured to allow:

• All branches – Any branch in the repository can deploy
• Protected branches – Only branches with protection rules
• Selected branches – Branches matching a set of name patterns

That means you can define a job to deploy in dev environment, and that job, as a condition, will only run if triggered from a commit pushed from a given branch (master in your case)

Answer 3

For anyone facing the same question or wanting to simplify their process away from gitflow, I'd recommend taking a look at this article. Whilst it doesn't talk about Github flow explicitly it does effectively provide one solution to the OP.

Purests may consider this to be not strictly Gitflow but to my mind it's a simple tweak that makes the deployment & CI/CD strategy more explicit in git. I prefer to have this approach rather than add some magic to the tooling which can make a process harder for devs to follow and understand.

I think the Gitflow intro is written fairly pragmatically as well:

Different teams may have different deployment strategies. For some, it may be best to deploy to a specially provisioned testing environment. For others, deploying directly to production may be the better choice...

The diagram in the article sums it up well:

So here we have Master == Gitflow main and the useful addition is the temporary release branch from which you can deploy to other environments such as development. What is worth considering is what you choose to call this temporary branch, in the above it's considered a release, in your process it may be a test branch, etc.

You can take or leave the squashing and tagging and the tooling will change between teams. Equally you may or may not care about actual version numbers.

This isn't a million miles away from VonC's answer, the difference is the process is more tightly defined and it's more towards having multiple developers merge into a single branch & apply fixes in order to get a new version ready for production. It may well be that you configure the deployment of this temporary branch via a naming convention as in his answer.