Structuring the Git repository
To implement GitOps, we require at least two repositories: the application repository and the
environment repository. This does not mean that you cannot combine the two, but for the sake of simplicity, let’s take a look at each of them separately.
The application repository
The application repository stores the application code. It is a repository in which your developers can actively develop the product that you run for your business. Typically, your builds result from this application code, and they end up as containers (if we use a container-based approach). Your application repository may or may not have environment-specific branches. Most organizations keep the application repository independent of the environment and focus on building semantic code versions using a branching strategy. Now, there are multiple branching strategies available to manage your code, such as Gitflow, GitHub flow, and any other branching strategy that suits your needs.
Gitflow is one of the most popular branching strategies that organizations use. That said, it is also one of the most complicated ones as it requires several kinds of branches (for instance, master, hotfixes, release branches, develop, and feature branches) and has a rigid structure. The structure of Gitflow is shown in the following diagram:
Figure 2.12 – Gitflow structure
A simplified way of doing things is using GitHub flow. It employs fewer branches and is easier to maintain. Typically, it contains a single master branch and many feature branches that eventually merge with the master branch. The master branch always has software that is ready to be deployed to the environments. You tag and version the code in the master branch, pick and deploy it, test it, and then promote it to higher environments. The following diagram shows GitHub flow in detail:
Figure 2.13 – GitHub flow
Note that you are free to create your branching strategy according to your needs and what works for you.
Tip
Choose Gitflow if you have a large team, a vast monolithic repository, and multiple releases running in parallel. Choose GitHub flow if you work for a fast-paced organization that releases updates several times a week and doesn’t use the concept of parallel releases. GitHub flow also typically works for microservices where changes are minor and quick.
Typically, application repositories do not have to worry too much about environments; they can focus more on creating deployable software versions.