Git limitations when pushing projects live using pipelines

36 Views Asked by At

We have several teams working on different projects, each using their own branch(es) in Git. Each team will then merge their branch into a common testing branch to allow system testing prior to moving the project to a user acceptance environment (uat) and ultimately the live environment. For different reasons, projects begin and end at different times and move along at different speeds. Projects with a high or critical priority may need to be tested and moved live within hours or days, much more quickly than dev projects which take months to complete and test.

However, once the individual project branches are merged into test, there is no way to promote/merge these branches individually to uat and then live. The uat and live branches have pipelines that automatically push the source to the relevant servers adding another layer of complexity.

As a project manager I would like to be able to see the status and location of individual projects.

I have asked this question in different ways before and have done a reasonable amount of research about the Git product and have come to the conclusion that there is no easy way to do this using Git.

Am I missing something - is there an easy way to achieve what I am looking for using Git? The solution must not overly tax or frustrate the dev teams - this will create more problems than it solves.

If not, is there another product that we can use instead of or in conjunction with Git?

1

There are 1 best solutions below

0
bk2204 On

Git itself doesn't have a way to perform deployments because these are considered orthogonal to version control. There are a variety of ways that this can be handled, though.

One way is to have separate branches for test, UAT, and production, and have each feature branch be merged into each of those in turn. While Git doesn't have the concept of pull requests, many Git servers do, and you can use these for this purpose.

Another is to have some sort of deployment system and have engineers deploy their branch to each environment in turn. This means that in some cases, you may want to be able to have multiple simultaneous deploys for some environments (like an early-stage test environment). If you need to have sign-offs from, say, QA, then you do that as part of the PR approval process. Once the final deploy is done, you merge into the main branch.

Both of these techniques are in use by major organizations, and there are of course other ways to do this that are different. It really just depends on what works for your team to handle this situation.