Branching strategy for frequent releases [duplicate]

We have very frequent releases and we use Git for version control. When i am mentioning about frequency, please assume it to include bug-fixes and feature release too. All releases are eventually merged into ‘mainline’. When a release is deployed on production and if a bug is identified, people start fixing the bug on the same branch from which the latest release was deployed on production. They do not create a new bug-fix branch for the same. I feel that’s not the right way to go for. There are several components and each component has a different owner, and thus, different perspective. Though I have not initiated talks with them, I am sure there will be a lot of resistance. Main issue that they might cite would be, “There’s a lot of work involved in creating and tracking branches especially when there are so frequent deployments on production. This will consume a lot of dev effort.”

Do you think that fixing bug on the same branch from which release was done, a good idea? If yes, how do you manage it? Using tags?

I know that best practices may not always be applicable due to several factors but still I would like to know what might be a good approach for branching in a scenario where releases/bug-fixes happen almost on a daily basis.

Edit: Thanks everyone for sharing your views and for the useful links. I think the main concern i have here is this: Do you think that fixing bug on the same branch from which release was done, a good idea? Is this approach fine in the long run or are we messing up things just to realize it later?

The important thing here is to have a consistent workflow which can be easily followed by both newbies and veterans in your organizations. Decide on a process which meets your requirements and ensure that the workflow makes sense for both trivial and more complex changes.

That said, there are a few standard workflows out there. Here’s a few of them:

GitHub Flow

GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly. Scott Chacon explains the differences from Git Flow here.

So, why don’t we use git-flow at GitHub? Well, the main issue is that
we deploy all the time. The git-flow process is designed largely
around the “release”. We don’t really have “releases” because we
deploy to production every day – often several times a day.

This site provides a great visual walkthrough for the GitHub Flow.

Git Flow

Git Flow

Git Flow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects. It defines specific branches for release, development, hot-fixes, etc. and the transitions between them.

There are a number of git extensions and tools available online to help support this workflow. Take a look at the nvie/gitflow extension for a starting point.

You can get a detailed explanation of the various stages and roles in the workflow here and here.

Reintegrating several times a day into the mainline is a fully valid strategy – it has indeed a name, it is called continuous integration. If this is a good strategy for your team or not depends mainly on how well your automatic tools for quality assurance are, and if your team is used to deliver “baby steps”. To apply CI with sucess, you should have an automatic build server running, a lot of automatic unit and integration test and ideally something like a (semi)automatic way of deploying (which includes versioning and tagging).

If that’s not the case, it is probably better to apply a more conservative model and to work with different branches, giving you the chance of collecting features and bug fixes in separate places before the final decision is made if the a specific change will be integrated into the mainline (or not).

It is of course possible to combine these strategies. For example, let the CI server deal with the mainline, from which your software is delivered. Develop every “new feature” in a development branch or separate feature branches. The latter are reintegrated into the mainline when they have reached a certain quality. Urgent bugfixes go directly into the mainline (and soon delivered from there) – because they are urgent. The feature branches prevent your team of bringing half-baked features into the mainline (and so unintentionally into production because of an urgent bug-fix delivery). Changes from the mainline should be at least once a day be reintegrated into all feature branches.

Other, more sophisticated models are possible, depending on the number of stakeholders involved (for example, do you have a QA team? How do they work? Which state of the software will they test?). What you have to do is to think about your environment and which model suits you best – what goals you have, what problems you see with the current model, and what you want to improve.

Filed under: softwareengineering - @ 02:56

Thẻ: branching, git, merging, release, version-control

Thiết kế website giá rẻ

Danh mục

Branching strategy for frequent releases [duplicate]