• Initial thoughts
• 1. First lines of code
• 2. First development environments
• 3. First stable environment
• 4. First production environment
• 5. First customers
• 6. Successful application
• Wrapping up
• Further reading

Initial thoughts

In this article, we will enhance our Git Workflow by gradually adding functionalities for starting web applications. Our main goal is to improve efficiency.

Developers, even experienced ones, have often struggled with the famous Gitflow :

However, the truth is that we don't need this complexity from day one. Many developers even argue that this level of complexity is never necessary in any case, but a symptom of an organisational problem.

Let's approach it differently: from team needs to workflow.

1. First lines of code

As we gather the team and prepare to write the first lines of code, the development team members have a few requirements:

• Share a common code base
• Collaborate on work in progress
• Conduct testing

Most web applications consist of a frontend module and a backend module. The question of using a multi-repo or mono-repo arises.

This article won't elaborate on the controversial topic, but for a starting web application project, we choose a mono-repo for the following reasons:

• No internal versioning required
• Local common module dependencies
• One feature, one feature branch
• Easy continuous integration

At this phase of the project, we don't need more than the following branches:

• Short-lived feature branches that are merged into main when ready, as frequently as possible
• A main branch for merged code

During the initial weeks of testing and demonstrations, local computers are sufficient. This allows time for the Platform Engineer to prepare real environments.

For code reviews, any Git platform, such as GitLab or GitHub, will suffice.

2. First development environments

Workflow

After a few weeks, code and features start to accumulate. Tracking bugs and conducting proper testing becomes essential. If the tools allow, these tests should occur before merging. Demonstrations should take place on a shared environment rather than on local computers.

To achieve this, we establish an integration environment that reflects the main branch.

If we have the right CI/CD technologies, we can also create an environment per branch, which greatly enhances team efficiency. Kubernetes and GitLab can help us achieve this goal with minimal effort.

Our Git workflow at this stage looks like this:

• Short-lived feature branches and their corresponding environments are merged into main
• main branch and environment are used for development team collaboration and client demonstrations

Separate Infrastructure Repository ?

This is controversial and a bit off-topic, but this still a linked matter with efficiency choice at stake.

Many teams choose to separate application and infrastructure repositories. However, I believe that the main reason for this separation is governance and politics, not efficiency.

We choose to have infrastructure scripts in the same repository as the code. Although the lifecycles are different, separating them can lead to complex pipelines if everything is automated, right?

But do we really need full automation for infrastructure? While infrastructure-as-code is desirable, deployment automation may not be necessary. We like to follow the rule: "do not automate before it is boring." Since our product is just starting, nothing is boring regarding infrastructure. We don't need to reinstantiate our Kubernetes cluster every week.

For these reasons, we code and version the infrastructure but do not automate its deployment.

3. First stable environment

Sooner or later, stakeholders will test the application. Frequent redeployment of the main environment leads to downtimes and occasional bugs, which spoil the experience.

It's time to introduce the demo environment. This environment reflects the content of the main environment and is updated before each scheduled demonstration. It remains stable in the interim.

To adapt the flow, the update can be triggered by a Git tag or a Git branch. Here, we choose to create a new demo Git branch.

Our Git workflow now looks like this:

• Short-lived feature branches and their corresponding environments are merged into main and then deleted
• main branch and environment are merged into demo before demonstrations
• demo branch and environment are used for demonstrations

4. First production environment

With the MVP (Minimum Viable Product) just around the corner, a production environment has been built from the ground up and will soon be made public. It's time to deploy our application to the target production infrastructure.

To adapt the flow, the production deployment can be triggered by a Git tag or a Git branch. We choose to use tags since we don't need to handle hot fixes at the moment, and triggering deployment jobs can be done manually.

We don't cascade merges from main to demo to production. The demo and production environments have decoupled lifecycles.

Our Git workflow now looks like this:

• Short-lived feature branches and their corresponding environments are merged into main and then deleted
• main branch and environment are merged into demo before demonstrations
• demo branch and environment are used for demonstrations
• Manual production deployment jobs are available on tags (created on main or demo, depending on the team preference)

5. First customers

As we had hoped from the beginning, we now have happy customers.

We want to ensure that we don't spoil their experience. When problems occur in their workflow, we want to be able to reproduce them in an iso-production environment, fix them, and test them in a pre-production environment as well. We will call this environment staging.

Since staging doesn't have real customers, we can deploy automatically using the same tags that trigger manual production deployment.

Our Git workflow now looks like this:

• Short-lived feature branches and their corresponding environments are merged into main and then deleted
• main branch and environment are merged into demo before demonstrations
• demo branch and environment are used for demonstrations
• Automatic staging deployment and manual production deployment are triggered by tags

We still don't handle production hot fixes separately. The entire content of main is deployed to production on tags. Unfinished content is not merged into main or deactivated by a commit.

6. Successful application

Now our application is somewhat successful, with many customers using it daily.

Cash is flowing, and the development team is growing. It becomes increasingly difficult to find a satisfying main or demo state to be deployed to production.

Now is the time to add feature toggles (also known as feature flags or feature flipping). Anything can be deployed to production as long as it is protected by a switch to activate it or not.

Our Git workflow now looks like this:

• Short-lived feature branches and their corresponding environments are merged into main and then deleted
• main branch and environment are merged into demo before demonstrations
• demo branch and environment are used for demonstrations
• Automatic staging and production deployment are triggered by tags created on main, and feature toggles are activated based on confidence

Wrapping up

We followed the journey of a starting project that progressively added only necessary complexity to the git flow.

By following this Git workflow, we believe that development teams can streamline their processes, improve collaboration, and efficiently deliver high-quality web applications to their customers.

What is your own best experience of Git workflow ? Please share in the comments below 🤓

Illustrations generated locally by Pinokio using Stable Cascade plugin

Further reading

This article was enhanced with the assistance of an AI language model to ensure clarity and accuracy in the content, as English is not my native language.