The Atlassian website includes a comparison of different workflow strategies available when concerned with Git. More strategies exist, like the one used by Linux Kernel team, but are not relevant to most organisations.
The workflow types most commonly used are -
Centralized - every change is added using a single branch.
Feature Branch - every change is ...
Let's say you take out the master branch (you can rename develop to master to confuse your team if you like later) and simply use tags for releases either on develop or hotfix branches. You took out a branch, but the difference is just a change in syntax. Change for change sake.
Now let's say you actually take out develop with keeping the locked master ...
Because you mention waterfall, I understand that the numerous branches you are alluding to are feature-branches rather than maintenance-branches.
In this setup, I also assume that these branches are created according to a waterfall plan that tries to minimise conflicts. This implies that the goal of the development is to produce several distinct products. ...
1) How can I run several different branches on the staging server?
2) How would I set up the DB evolution system to make sure it always has appropriate DB for each branch?
This depends on how much you expect your DB to scale. You can get pretty crazy with methods to clone database data but typically you will want a master copy that you do not ...
When migrating from something to something else, there are only two things you need to define:
What is your target
How to get there (the migration plan)
The first part is, sadly, often overlooked or way too vague. You cannot simply say that what you have is a mess and you want to organize it. What would that mean? Everybody would have a different ...
IMHO the problems you're facing are just a side effect of the poor branch strategy you started with: you're effectively plowing new development on develop (i.e. what converges towards the future production code) through the current production code on master. This leads to contradicting requirements and problems since typicaly the future code diverges from ...
You are already building and testing code on each of the pull-request and hot-fix branches. This means that in aggregate, the sum of all branches pending on pull-request are your virtual develop branch.
You can create a system when in a test environment, several pull-requests are cherry picked into a temporary branch that is not published to the main ...
The simplest/cleanest branch strategy is IMHO the one used in continuous deployment: a single/main integration branch which is also your release branch. From What is Your Branching Model?:
Commits can go all the way to production from one trunk/master, if the
automated build says the commit was good. It’s the turbo-switch for
TBD, where no ...
As Michael mentioned, offer a standard solution based on release versions/numbers, with a reasonably long lifespan for your industry (maybe interleaved with one or more shorter lifespan intermediate versions, if it makes sense for your typical customers).
Give your customers the option to embark on this standard release track, maybe with a decent migration ...
There are different strategies and, depending on your specific problem domain, you need to decide what makes sense for you.
For server side applications, especially micro services, you typically don't need release branches. You can work with pull requests, but once they hit master, it is common to deploy (from master) and never look back. Managing release ...
Since you have a single released version product one thing to consider would be keeping the Develop branch or not:
keeping it would have the advantage that at any moment you can bring in a hotfix in master even if Develop isn't stable enough for a merge into master. But this means you'd need to have 2 focus points instead of a single one - both branches ...
Branching strategy is a very clearly a business decision in which the DevOps engineer should be the primary expert, explaining all the trade offs. There are some strong positions on this issue in the community, very clearly Jez Humble is on one side with his book of Continuous Delivery. You could see him talking about it here. Here would be a video by panel ...
It is actually very simple to convert a multi-branched hydra repository into a single branched model.
First, you want to start with the branches which have the least difference between itself and master or trunk. Examine their age and relevance. If they are still relevant, start merging them together and resolving conflicts. If they are no longer relevant, ...
Well @dan-cornilescu says it well for your particular problem, but the more general case for Trunk-Based Development (mentioned in the Continuous Delivery, Lean Enterprise, and The DevOps Handbook) is made here: https://trunkbaseddevelopment.com/
You can read book about best practices for git: https://git-scm.com/book/en/v2
Example for some git strategy in project:
Creates branch named like a task, feature/XXX-1
Sending task for review
If not review, fixes and again review
If reviewed go to test
If test not passed, fixed and again review/tests
First time review:
git pull dev
git checkout -b ...
I'd argue that this isn't actually about staging servers. A staging server closely mimics the production environment, and is where a release goes immediately prior to going to production. A feature branch that hasn't been merged into master is not going to be released directly to production, so it should not go on a staging server.
If we reframe the ...
You've discovered one of the great pitfalls with TFVC. I have also not found an answer to this issue.
The only possible option I've seen around getting code from TFVC out of different branches is to base your pipeline off the highest point of the source tree possible (i.e. the highest common parent folder of all branches) and always build using source ...
Maybe if you maintained branches per versions instead of per customers it could help reduce their number?
Otherwise the only way to really get away from it is to be able to host the software yourself and switch to a SaaS model where you would be able to maintain only one version of it.
What is the recommended practice?
The book ”Accelerate” by Forsgen, Humble and Kim documents their research that teams that use fewer long-lived branches are more successful.
The question is then what is the best minimum set of branches for a given team. The answer to that, like many things, is ”it depends”. A team that pushes into production a dozen times ...
A few questions so I can better understand your use case:
How often would this deployment/build of yours be run?
Will there ever be any changes going into Master that do not come from develop?
If you plan to run this deploy/build which would create a PR to merge to Master for each change in develop, then I would recommend to delete the develop branch and ...
I would look into Azure Functions. Create a gate trigger and enable azure function after a successful release.
You can create a release process to manage deployments in your environments.
A plugin that can help you is the maven-release-plugin, where you 'freeze' the package and can promote them between environments (DEV -> UAT -> PROD). This ensures that the artifact (package) is exactly the same as the Production environment.