I need to bring a site to version control, and set up the continuous Integration environment

Question

I am an entrepreneur with a Drupal 6x project that started small enough to not need version control (per developers), but now I am convinced there is no way without it. There's extensive documentation on JIRA, complete with well-written User Stories covering everything. I read up a bit about how this could be done and came up with the following plan -

1. Separate site code from database using modules
   1. Context
   2. Features
   3. Strongarm
   4. Profiler
2. Put the code in a SVN repository and create a staging site
3. Create a mirror of the staging server on EC2 production server
4. Create Selenium tests, and run them on the cloud using Saucelabs
5. Create a build workflow in JIRA Studio using Elastic Bamboo to run automatic updates
6. Update and install profiles using Drush Make
7. Run updates on production server (I am not sure how)

To begin with, I have made a list of about 50 "Features", each with its components (views, content types, modules etc). This will no doubt be challenging as the site contains about a dozen custom modules and web services, not to mention another dozen instances of content type "application" containing custom code (most of which I would like to have converted to upgradable views or modules). The good thing is that the site is not yet in production so the risk is still limited.

Does anyone have any experience in doing something similar? What pitfalls and limitations should I expect to encounter? I would greatly appreciate any suggestions for improving/correcting the above plan, or any insight or advice that you experts out there might have for me.

Answer 1

Ok, I'll give this a try :) I won't be able to fully answer your question, but maybe give you have few interesting hints. Note that my numbering is not in direct response to yours :)

1. As I already mentioned in the comment, no project is too small for version control. I personally recommend Git. Reasons are the plain awesome speed of it (wait time in git is measured in milliseconds, not seconds) and the huge amount of features. It can be a bit hard to pick up, because of weird names and arguments but the following documentation explains many of them really good: http://www.eecs.harvard.edu/~cduan/technical/git/. Another reason is that it is now used by drupal.org, so knowing git will help you when you want to contribute back (providing patches, testing patches, release modules, ...)

2. That said, if you'd like to use SVN for some reason (like integration with services you plan to use), then go for it. SVN works reasonable well too and is much better than no source control. (Unless you ask Linus Torvalds..). Also, there are often ways to migrate from one VCS to another if you change your mind. SVN -> Git works well, for example.

3. Third, approach this step by step. Don't try to do everything at once. Give you (and your developers) the time to learn the new tools.

4. Switching from Drupal 6 to Drupal 7 is not a trivial thing. Especially with a lot custom code. Note only are there tons of API changes and new concepts (like the entity/field system), there is also the point that many contributed modules aren't fully ready yet.

5. Deployment management is one of the weak points of Drupal, that also hasn't changed that much in Drupal 7. We are aware of the problem and people are working hard to resolve this for Drupal 8: http://groups.drupal.org/build-systems-change-management/cmi. Features etc. helps, but it's not a silver bullet. Not everything can be exported as a feature.

6. There are also a few Drupal-specifc options for deploying staging/production sites. Pantheon (still in beta) and Acquia Dev Cloud might be worth checking out.

7. Continuous integration, automated testing is important and really useful but also require time to set up, write the tests and so on. Time you might or might not have at this point. But especially automated tests is an area where it is easy to do incremental improvements. Once you have a environment set up to run them, you can write more and more tests as time permits.

So, here is my recommendation for the updated question in the comment:

Finish and release as is, but start using a VCS (version control system) for Drupal 6 now. Create a staging environment for your site. Look at what (contributed) modules you are using and check if a port to Drupal 7 is feasable at that point. Don't underestimate the time that will take. Also start to improve the testing/deployment process, starting with what you think will bring you the most benefits/cost.

You can also create more specific follow-up questions or look those which already exist. As you can see, even only giving a few hints to a question like this can get huge and take quite a bit of time.