Quote:
Originally Posted by Shap
For all of you saying you try to update daily and multiple times a day how do you track if you made a positive or negative change with so many changes? We limit our changes so we can isolate the positive, neutral and negative changes we make.
|
AB AB AB AB AB AB, hahahaha.
My preferred method:
Git repository control... if you don't have some sort of source control going on, you're doing it wrong. These next few paragraphs will show some of the advantages of git over svn...
New Features are developed independently / jointly by developers and each new feature is developed in its own git branch. I use Redmine quite a bit for issue tracking so each branch then becomes named using its redmine ticket id and a brief description: 3215-AB-New-Join-Page.
When a commit is made developers can use keywords in the commit message like: resolves #3215 which automatically pushes the Redmine ticket status to Resolved. From there it is deployed to the staging environment and QA can change the ticket from Resolved to Confirmed; meaning it's production ready.
For a site rollout, all branches marked confirmed are combined into a single revision and get tagged... production-20101025-1 That tag is then used to deploy the code base across all production nodes.
A/B results are monitored and then if something needs to be removed, or the A/B test has been decided you can rebase your code by simply removing the commits that were done in a given branch (keeping with our example, 3215-AB-New-Join-Page).
It's a pretty nice workflow and allows you to roll any piece of functionality in and out of deployment very easily. Of course, you need to have a well designed A/B Engine that keeps in mind your development pattern as well as reporting requirements so you can make educated decisions based on accurate results.