5

In my (small) company, we are currently thinking about dumping our current versioning system (svn) and release procedures, which are crap TBH, and switching to git. It will mainly be used for one large web project which we will be continously developing for some years, at least. Considering what I found on the web and some questions here on Programmers.SE, I came up with the following workflow (based on the gitflow workflow):

We have three web servers called live, webtest and webdev, and three main branches, master, testing (branched from master) and development (branched from testing). The code in master will always be exactly the one deployed in the live (production) system, and the code in testing will always be exactly the one deployed on the webtest server. The webdev server, however, will be continously used by the developers to upload their code, so it does not necessarily correspond to the development branch.

Whenever a developer starts working on a new feature, he creates a feature branch from development, works on it (and frequently uploads his current progress to webdev), commits to development from time to time, and whenever he thinks he's done, he merges back his feature branch back into development (1).

Whenever a bunch of features is ready (and possibly reviewed by other developers), we merge development into testing (and this code is deployed on webtest), so it can be tested (2). When the testing in done and everything seems fine, we merge testing back into master (3), and the code in master is deployed on the live production server.

I have some questions about this: In (1), (2) and (3), would it make sense to create pull requests rather than just merging? How would we approach errors found in testing - by creating branches off testing or by fixing it in the respective feature branch and then merging back into development and testing? Are there any other major drawbacks or caveats I have overlooked? Do you have any other enhancements or suggestions?

Improve this question
3
  • 3
    It seems pretty complex. What I would do in your case is: learn about the original git flow and try to use it, add the complexity as needed. You might find out that it fits your necessities. For instance, you might not need the testing branch (it has no development running into it, you are just using it because the code is under test. You could use tags for that. In my case, development is everything that is "testable". Every programmer that is working on a feature has his/her own branch Commented Jun 5, 2015 at 7:21
  • It also depends of the techniques & methodologies used for your web development. Developing a web application with HOP or Ocsigen is very different (and more productive) -since they enable easy mixed browser&server programming- than working the old fashioned way in PHP + Javascript. Commented Jun 5, 2015 at 7:23
  • We added the testing branch because we have the webtest server where beta users can test new stuff and we can't let them test on webdev because over there things are frequently broken while developers make their changes. The problem in web development (at least in our case) is that the developers can't actually develop on their own machines, but have to upload their changes to webdev to see their effects. Commented Jun 5, 2015 at 8:50

2 Answers 2

Reset to default
8

This is very similar to a successful git branching model that we've employed in my workplace - it works wonders for us (though we differ slightly from your branching a little, and put the git tag on production server so that devs don't patch live and update git via production server (and possibly fubar the branches)).

When developing

Your proposed method is great. Every developer has their own workplace (on the server) and they have their own [feature] branches - this will be great help as you'll be able to track what features are in development, where in the development lifecycle they are, and who is responsible for them (though if you adopt agile workflow, you'll know this; it's nice to know when you look back in the past).

Developers having their own [feature] branch when developing will allow you to work on different features without overwriting each others work.

This stage is fine, no caveats

When testing

Testing can become confusing, because what if you find a major bug that needs patching but feature X is ready to go live? Who is responsible for the testing?

Fixing a bug during testing

When you have your testing branch on the test server and you find a bug that needs patching, it can be addressed 2 ways;

  • Checkout of testing branch into a bug fix (bf-) branch. When there is a bug, usually I create an issue detailing what needs patching and name the bug fix branch after it (ie: opened issue #293, the branch will be bf-293). This will greatly help you track what was fixed.
  • Directly patch the testing branch.

Testing multiple features

Again, very easy to do with your proposed branching model. Ensure you create a pull/merge request to document what code was changed (this has saved my bacon many times in the past) and at what stage in the products lifecycle a particular feature went into testing and production.

Once all features have been merged into the development branch, ensure you create a fresh testing branch (I usually name these release candidates. Ie: we are testing v2.42, I will name this testing branch rc-2.42) and push up to the testing server.

This stage is fine, no caveats

Go live

Going live with git is great. Once you're happy with your test results and ready to push live, ensure you open a pull/merge request so that it's documented what is going live when (as previously mentioned).

! If you fixed some bugs during testing then make sure you merge the testing branch back into development. You don't want things that are in master and not development - things will get messy and confusing very quickly.

Once merged into master, ensure you tag it to create a point in time to roll back to (I'll explain later). When you go live, ensure you checkout into the new tag so that you cannot patch live without going through the git procedure.

When you've gone live, I like to create a post in the wiki to document the new version and link the pull/merge request. It will be much easier to track what went live.

Why use the tag?

Tagging creates a point in time that is very easy to rollback to should something go terribly wrong on the production server. It also manages your visioning and nice to look back in time to see what went live when.

Conclusion;

  • Your branching model is fine
  • Make sure you open pull/merge requests before merging
  • Ensure you tag your master branch
  • Ensure you document the push to production (in the wiki)
  • When patching (either hot fix or bug fix), ensure you create an issue to document the bug.

enter image description here

Improve this answer
6
  • First of all, thank you for your detailed answer! One follow-up question: We don't really plan to have formal "releases" and version numbers, which is why we don't just adopt the gitflow model. Is it really necessary to repeatedly create fresh testing branches? Can't we just keep on working on one? Commented Jun 5, 2015 at 9:05
  • May I ask why you don't plan to have version numbers? It'll help with tracking the core version, features and hot/bug fixes that are currently on live (ie: production is on v2.5 and testing is on v2.7.9 - Ah, we've got 2 features and 9 bug fixes to go live (it wouldn't be this severe, but you get the idea)). Creating fresh test branches should be a necessity as once you've merged (into master to go live), you'd delete the branch to clean up your project and not cause confusion (ah, we have a test branch, but is it all live?) Commented Jun 5, 2015 at 9:09
  • Well, as most websites, it will be developed continously and will not be marketed with version numbers or anything, those would be solely for internal use. Therefore we rather thought about revision numbers or timestamps. In our (current) model, development is branched off testing, which makes me wonder whether we can simply delete it and create a new one. Commented Jun 5, 2015 at 9:27
  • The version numbers aren't published, but I am certain they are used internally. Personally I prefer the v<core version>.<feature release>.<bug fixes> idea than timestamp, but that's for you and your team to discuss. testing should be branched off development as development is continuously updated and should hold the stable version (testing isn't always stable) Commented Jun 5, 2015 at 9:33
  • testing is not stable, but development is? Shouldn't testing be more stable, because it is updated less frequently and only after some testing has been done by the developers? Commented Jun 5, 2015 at 10:52
2

The standard git flow model should work fine for you based on what you've said. Here's how we use it:

  1. All work is done on develop (or a feature branch if we might want to do a release before a given feature is complete).
  2. When we are ready to call something a release, we create a release branch from develop and deploy this to test.
  3. Any bugs that are raised in test are triaged and either fixed on the release branch or - if we can live without fixing them - tucked away for a later release. During this time, further work can be started on develop (with any release fixes being merged back down regularly to avoid a mega-merge later).
  4. The release branch is deployed to our acceptance environment - the same cycle occurs, except with the testing done by clients.
  5. When everyone is happy with the release branch, it's merged back down to master/develop and deployed to production.

This is pretty flexible - it's also very robust because your release -> master merge is always a fast-forward (so no regression or conflicts when you go to production) and it forces you only to test one release at a time, which means you don't end up with changes on an earlier release branch undermining test validity on a later one. It also means test is stable at any given time and not subject to a trickle of deployments that risk undermining testing.

Things would get quite complicated if you started doing bugfixes on feature branches - you've then got to merge those branches back into the release via develop which might have other work on it... Once your feature branches are merged, they are effectively "done" and any further work - even on that feature - should either be done on develop, a new feature branch or directly in a release branch prior to go-live.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.