41

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.

  • Its a very interesting question. That's something I thought of implementing in my website as well, but gave up as it didn't seem efficient. If you go through with it, please give us your input. – Tivie Jun 2 '11 at 6:47
  • 3
    Definitly an interesting question, but also hard to answer. You're asking multiple questions, so it is hard to give you a complete/best answer. Just one hint: IMHO, no project is too small for version control. Especially now with distributed VCS like git, it takes like 5s to put your code in a local repository. See also drupal.stackexchange.com/questions/316/… – Berdir Jun 2 '11 at 8:35
  • In retrospect, indeed no project is too small for version control (if I only knew it then). I went through that link and it brings up yet another important question. If we are to pull Drupal core from its own git repository, should we be using git for Drupal projects instead of SVN? The reason we're using SVN is because there is native support for it in JIRA Studio which is important for us given that we want to use JIRA's automated build features (Elastic Bamboo). Sorry for the multiple questions :-( – druflex Jun 3 '11 at 0:20
  • UPDATE: After a code review, it was determined that there is much custom code in the project, which will be really difficult to export using features. So the options in front of us are - (1) Finish and release as is, and start parallel development in D7 using proper version control. This means wrangling the database later. Scary. (2) Redo essential features in D6, release, then do Continuous Integration. (3) Redo essential features in D7, release, then do Continuous Integration. The main question is how much time each of these options will take. If you were me, what would you vote for? – druflex Jun 4 '11 at 1:09
23
+50

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.

  • Thank you so very much for such a great comprehensive answer. I am pretty much decided on exactly what you recommend. Even including Git actually. I will move JIRA from hosted to standalone so I can use the Git plugin. So D6 it is. Release current version now, and start re-creating a proper best-practices copy in parallel, using as much existing code as possible. Thanks again for the support. Cheers! – druflex Jun 6 '11 at 16:48
  • +1 Good advice, comprehensive, down-to-earth streetwise and real. You're speaking from experience. Thanks. – therobyouknow Feb 14 '12 at 10:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.