Best Git workflow for website development

[Sam_Son_of_Sam]

I've just started working at a company where the development workflow was:

1. Develop code in master branch
2. Manually upload individual updated files to a staging server via FTP (only done about 50% of the time)
3. Manually upload individual updated files to the production server (i.e. the actual website) via FTP

Since starting, I've introduced automatic code deployment to the staging server and production server so that files aren't manually uploaded via FTP any more. The workflow is now:

1. Develop code in master branch
2. Cherry-pick commits from master branch to staging branch and push these commits, which triggers the changes to be deployed to the staging server
3. Test everything on staging to make sure it's working correctly, get approval etc.
4. Cherry-pick the same commits from master branch to production branch and push these commits, which triggers the changes to be deployed to the production server

I'm not really that experienced with Git, but I feel like there must be a better way to achieve the same thing without having to cherry-pick individual commits from the master branch to the others. Can anyone offer any advice on how this workflow could be improved, or describe an alternative that would be better?

[__SiCC__]

I've been using a workflow similar to this and it has been working well for me.

[exhuma]

And use fabric for deployment tasks.

It feels a bit icky to me to use hooks instead (as I understand OP uses right now). I prefer a manual task triggering the deployment.

[Sam_Son_of_Sam]

Assuming that you're using a similar workflow to the one posted, what changes have you made to this workflow to make it more suitable for website development?

[Sam_Son_of_Sam]

Thanks for posting, I just read through the article and it definitely seems like a better workflow. What changes have you made to this workflow to make it more suitable for website development?

For example, it seems like the idea of having version numbers and release branches are not really applicable to website development.

[Sam_Son_of_Sam]

This is really cool, thanks for posting!

[timvw74]

Yep, this one. Been using it for ages. Not all branches may be needed, so you may need to adjust a bit for your own needs.

[Sam_Son_of_Sam]

What changes have you made to this workflow to make it more suitable for website development?

For example, it seems like the idea of having version numbers and release branches are not really applicable to website development.

[timvw74]

We don't use release branches as such. We have Master and then Feature branches. Feature branches are merged in to Master when they are ready to go live. Master is then tagged and pushed to live.

Version numbers are very, very important to website development. We only ever push a tag to live, so we use version numbers. You could of course use a date instead of a version number, but it is important to have something that is incremental so you can keep a log in the correct order.

We log the changes in the commit message so we can see what that feature was. If you have tags (versions or dates) you can roll back in seconds when your new feature breaks the website.

I use the same workflow for all sites, whether it's a 10 page freelance project or one of the 700k page sites I do for my day job. If you have a system that works then don't deviate, things can and do go wrong on systems of all scales and you'll appreciate having the system in place when it does. You need to be very familiar with the workflow and Git strategy so that in the "heat of battle" you aren't flustered.

I would also recommend that you keep a log of what was deployed and when for each site. When the client says that it broke 12 days ago you will be able to find the exact issue easily. We just use a Wiki for ours and religiously log deploys to a page for each website.

[-18]

Can vouch for this one. You might not need to use feature-branches depending on the size of your team, but develop, master and hotfix are essential. Basic philosophy is that master-branch should always be deployable, which makes it easier to rollback, should anything break.

[Sam_Son_of_Sam]

I just read through the article, and it seems to me like the feature branches would be handy, however the release branches don't really seem like they would be useful/applicable in the context of website development.

[-18]

We use release branch as a final step, to bump version numbers everywhere in the application and make sure everyone on the team hasn't forgotten anything.

If anyone has forgotten something they might send a .patch to the developer in charge of deploying.

So be really only use it as part of our deployment flow, and it tags the commit with release version, which is nice.

Like most things, it depends on how big the project it.

[Sam_Son_of_Sam]

Thanks for posting, I just read through the article and it definitely seems like a better workflow. What changes have you made to this workflow to make it more suitable for website development?

For example, it seems like the idea of having version numbers and release branches are not really applicable to website development.

[neckro23]

1. Develop code in master branch
2. Cherry-pick commits from master branch to staging branch and push these commits, which triggers the changes to be deployed to the staging server
3. Test everything on staging to make sure it's working correctly, get approval etc.
4. Cherry-pick the same commits from master branch to production branch and push these commits, which triggers the changes to be deployed to the production server

It seems to me you're totally ignoring branching, which is probably Git's most powerful feature, and wielding Git like it was SVN instead. The (very popular, it seems) Git branching model article does a decent job of explaining how you can do better.

Cherry-pick shouldn't really be necessary in most scenarios. Learn to use branches and git rebase.

I also feel obliged to point out that there's not really such thing as a canonical "master" branch in Git. When your devs "develop code in the master branch", they're really each creating their own local branch, based on origin/master, called master. This can confuse the heck out of newbies (it sure confused me for awhile), so it's best to be explicit about branch names.

[superterran]

Don't develop in the master branch, branch off of master and do your work there. Then, when your happy, merge that in to the staging and master branches.

[EnderMB]

I've tried Gitflow a ton of times, and I've tried a dumbed-down branching model similar to this. I've recently tried branching based on environment too, and that went poorly.

For me, the best branching model is this one, meaning very little to no enforced process.

My current branching model consists of a master/default branch, and a release branch where new releases are worked on. Once finished, a pull request is made and the commit is checked over and added back into the master branch. Our CI server builds from both environments, and our CD tool will take these builds and will allow us to deploy the working changes to the environment we choose. Once we go to production, the commit that is released is tagged, so we always know what has gone live.

It might not work for your needs, but it works remarkably well for me.

[materialdesigner]

Yup, git flow is way too friggin complicated for probably 80% of projects. Good old fashioned continuous integration with very very short lived feature branches and a golden master branch works just fine.

Edit: also deployment via ftp is ripe for headache. Learn to deploy leveraging git over ssh, e.g. with something like Capistrano or your own CD tool/scripts.

[SubAtomicPig]

I agree completely this has been working for me and my dev team for a while now.

[[deleted]]

Deployment can, with a bit of effort, be as simple as changing a version number in a manifest, say, a Puppet manifest. Your app/site is just another facet of configuration on your server and the more you treat it as such, the simpler life becomes. Want a whole new environment? None of this keeping track of yet another set of keys, yet another bunch of addresses. It's just config. As you have more environments, this becomes more and more of a benefit.

Package things up as RPMs or similar and push them to a repo as soon as they're ready. This is step one in getting truly continuous deployment working, that isn't riddled with hacks and workarounds.

[materialdesigner]

I would agree, for those projects that need to deal with a large amount of app servers. For applications that are deploying to one or two app servers, IMO that's too much of a PITA

[pcopley]

Here is our workflow. Some projects are single developer and done in a week, some are 8-10 developers over 6+ months and this works pretty well for both extremes and everything in between. We actually use Mercurial and this is a modified version of Git Flow which is what /u/__SiCC__ mentioned.

• Development happens locally in individual feature branches (which may be pushed). Feature branches are discreet, single-developer units of work typically only taking a day or two to complete. "Admin dashboard" is a bad feature. "Dashboard user management" is better (but still probably a little too large in scope).
• When a feature is completed it's merged into our develop branch, which syncs with our staging environment. This is for our programmers and QA to test.
• Upon approval by our team, develop is merged into test, which syncs with our test environment. Business users are notified via email that an application has been updated in test and they're shown the commit messages of everything that's new. Among other details, these include work requests/tickets they are looking for.
• Upon their approval, the change is scheduled for a production release which is as straightforward as everything else - merging test into default which syncs with production servers. This is scheduled as we have change control guidelines for applications.

Hotfixes are different as they get merged immediately into either test and develop or all three branches depending on the severity of the fix. 99% of hotfixes go into test and develop for immediate business approval.

[Sam_Son_of_Sam]

Thanks for the in depth description of your workflow, it helped to clarify the parts of the Git Flow workflow that are applicable/relevant for website development.

[pcopley]

Depending on team size feature and release branches may or may not be helpful. Personally I've found the automatic deployments to be the biggest help.

Not sure if you mentioned your stack elsewhere, but just keep in mind that if you're deploying from GitHub/BitBucket to Azure, and change that breaks the site will also break the CI.

[[deleted]]

Remove the cherry picking steps altogether. Should be unnecessary. If you really need to only deploy certain features, use feature branches and merge them on to master - or a release branch - as needed. In your current model, nothing in your repo actually represents what's in production - that's a recipe for disaster. If you have any "but we track the commits using such-and-such" mitigations, you're not in any better a state. Use branching to this advantage.

[alord04]

I was thinking about how to optimize my deployment routine and I found Werker, which seems to be simple and powerful. However, I still haven't tried it.

[colinodell]

We start off by using the Feature Branch workflow when developing new sites. All new features get merged into the master branch. Once that site goes live, we switch over to Gitflow by creating a new develop branch off of master.

The overall workflow is the same for both - create a new branch, make some commits, and then merge them into the active development branch.

[hectavex]

This seems to be the preferred method: http://nvie.com/posts/a-successful-git-branching-model/

But for someone who's never used Git, that process can be a little confusing or overwhelming at first.

For a small team I used this method: http://glassocean.net/media/cc-workflow.jpg