8

I've been reading up a lot lately on various web application deployment processes using SVN or GIT, with a view to redesigning how we currently deploy where I work.

As is the way with many flavours of Agile, it's assumed that anything committed to master or trunk is production ready. Both GitHub and Etsy, http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/ say that they work on this basis (although Etsy actually have a staging environment).

This process assumes all unit test and CI tests have been run. You run the tests locally and on CI and then commit to trunk. SO, at this point your code is technically sound.

Your code may be technically correct, but user/functional testing may unearth more bugs, particularly when it comes to front end testing.

My question is this. Where do QA and Business owners test the feature changes you have implemented? On your local development machine before you commit to trunk, or on a QA/staging machine?

If you have a staging machine that runs off trunk, and you assume that all code committed to trunk is production ready ... eh .. then at what point is the code signed off and good to go into production from both a technical and business perspective? If you have only one staging machine, many developers and that is where the code is to be QA'd, then how can you deploy from trunk as many developer changes can be waiting for sign off.

I'd be interested to hear how others have approached this?

Improve this question

3 Answers 3

Reset to default
6

For better or worse I usually see this done where the testing is done against the branch base and the business sign off is what the checkpoint is to merge to the deploy main.

I have seen this done both with development on "main" with a separate "deployed" branch or a development "feature" branch with a main as "deployed".

the workflow ends up looking something like this:

  • code something
  • run local tests
  • check in to working branch
  • (optional) build server builds ant tests
  • QA/Business testing
  • bugfixes (loop back to top)
  • merge to deploy branch
  • deploy

Some folks work out of a single branch, but if you are going to have manual testing that gets difficult. Most people I have encountered that work on the assumption that anything can be deployed on commit that also work out of a single trunk are doing something small, or have a HUGE amount of automated testing, OR they consider the "deploy" in this conversation to be a build to a testing server and the process of QA that happens between the testing server and production is handled separately.

Improve this answer
3
  • Thanks Bill. We work in an environment where developers are constantly committing and deploying separate pieces of functionality for the site. If working on a feature branch, after checking in working branch, where do you see the QA/Business testing being done? If you have just one QA machine that developers commit branches to, then realistically only one feature can be tested at a time, unless you perhaps has a site and separate instance of the application server set up for each developer on the QA machine, so his changes could be tested in isolation before committing to trunk. Commented Oct 16, 2011 at 17:36
  • in my experience with this usually we did not make a separate feature branch for each dev, more like one for each team and we did set up a qa host for each of those even if it was just an extra dev machine. Commented Oct 16, 2011 at 18:50
  • Appreciate the comments. Has given me some ideas. Commented Oct 19, 2011 at 16:40
2

We have automated acceptance tests on the same feature branch. When you make a release candidate, it includes the automated tests you ran to see if the feature passes. You also test the release candidate. When everything passes, you promote it then by merging to master.

More on this process here:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Do checkout the comments as well.

Hope this helps,

Adam

Improve this answer
1
  • @Adam - Thanks for that, and the link. The discussion there was is interesting. Food for thought. Commented Oct 16, 2011 at 14:22
0

As a general rule, waiting to commit before the code is perfect is half the time take back the advantages of version control system. (Without much elaboration, i would say that unless one is allowed multiple check-ins to VCS, one has no way to revert my own work!) So as a practice we always ask people to keep check-in (within their branch for SVN or it can be local commits in case of GIT) as much as they want. In fact the more the better.

However, when the point arrives where everything appears to be done and tested - we call it a release and then it is merged with trunk. Essentially, QA can certify the RC by taking a fresh check out on the HEAD of the branch and if he/she Okey's it, the same is merge back with trunk.

So essentially we use the concept of task-branches or private-branches so people are free to make check-ins as much as they need. At the same time, trunk is relatively free from any broken check-ins.

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.