Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By KaraUrban on
We are looking for some sort of version control and did not want to use the command line for it. The development environment is windows and people have tortoise svn for other projects. Does anyone see any problems with this workflow?
1) have a svn server than can be reached by all relevant machines (dev/test/prod and developer workstations)
2) put a fresh install of drupal on dev, import the whole site into svn, put a mysqldump out there that can be imported
3) on the developer workstations check out ONLY the /sites subdirectory into the local drupal /sites folder (or a directory not in the wwwroot tree if you prefer) after installing drupal
4) commit, update, etc as normal - if there is a change to the look of the site (content, themes, new module, etc) beyond the module code update the mysqldump file so other developers can use it for their own local databases
5) when the core code is updated do so on the dev server and pull down the latest modules ... if everything is okay again check it in and have developers update their own core code distros & repull the modules
I was looking around the web and there seems to be a lot of contradictory information about version control in drupal and no complete advice for our setup. As far as I can test everything here works. Does anyone see any problems either from a best practices or procedural standpoint?
Comments
Avoid versioning the database dump
Because D7 mingles configuration and content, versioning the database almost guarantees that you will at some point accidentally either overwrite production content or promote test content to production.
We always (well, almost always) use the Features module for exporting and versioning configuration. Mike Stiv just wrote a quick overview on it the other day that you may find useful: http://www.mikestiv.com/blog/features-module-explained
I'm also not a big fan of checking core into source control. If you are using a distribution for your site, you can build the whole thing cleanly with only a few files checked into source control. Start here for info on that: https://www.drupal.org/node/159730
Thanks, still looking for a workable VC solution though
Thanks, but I am reading up on the features module and it may not be the right tool. We want something that is BAM! checked in then BAM! checked out. A multi-step version control process and a learning curve would soon not be used by anyone writing for the site. Since it involves drush that also keeps it out of contention (yes, I know, Drush is powerful, but our parameters involve doing everything at the GUI level).
I fully expect that the developers will be concentrating on new php code for custom modules for the most part after the initial look&feel of the site is set up. When the look changes the database dump would also change and they could update their environments accordingly. So there would be no versioning of the database once we have the environment it would live in. Another document about drupal version control took the same approach: have the database dump somewhere the developers and the servers can access it, like on a networked drive.
The full site (minus the database) would be kept in our VCS but developers would just check out the sites subdirectory the vast majority of the time. In this way it would be like there was a repository for their modules but the whole thing would be there so the site could be reconstructed if needed (like a server going down at 3 am).
After going live in production we would need to back up the mysql database as usual of course, but that is not the issue this would address.
So again, does the procedure I outlined sound like a good one based on the parameters? How about from a standpoint of good practice?
The features module is one of
The features module is one of the best development tools out there, and does not require drush.
Yes, it does look powerful.
Yes, it does look powerful. Thanks for the info that it allows for not using drush. Maybe I should give some background.
Essentially we want something that can be implemented now and for the short term since we know our procedure will change. In the near future our team will expand, including adding a more experienced Drupal person, however we do not know what their past experience is yet. When that person arrives I can debate the merits of different methodologies (including features, which I will read up more on) with them and we will change our group's workflow based on what they are used to. For now though we just want a stopgap solution that our currently small group can get up and running with rather than spending a lot of time training everyone on a procedure that a new person may or may not want to change based on our environment, their expertise and several things that are in flux right now. Which is why I do not want to try to craft the 'perfect' solution for us but rather something that I can use for now.
ANYTHING has to be better than doing things like creating file.php.old. :)
My apologies for not including that information but how does my proposal sound now?
_
Unfortunately, that doesn't exist yet.
No it doesn't-- for all the reasons already mentioned. It's fragile and prone to breakage. It's not a matter of if, but when. 'best practice', as far as it currently exists, is features. i'm not a fan myself and had problems using it in the past. I've taken to using a custom deployment module which has it's own set of issues.
The good news is that with D8 CMI the dev-qa-prod deployment workflow will become trivial.
Yes, I read that 8 will keep
Yes, I read that 8 will keep everything in files ... which will make things a LOT easier!
As to when it breaks that is less important as I only need a method that will hold us over for the short term. It will exclusively be worried about the code for custom modules so it is not like a lot of database settings can get trampled.