Acquia Cloud will be adding native support for git soon, but it is already the version control system (VCS) of choice for many developers. You can develop and host existing projects on the Acquia Cloud right now using git–or many other VCS’s: Subversion (svn), bazaar (bzr), mercurial (hg), CVS, and more–with a one-time setup of your development environment.
Acquia's Jakub Suchy did a nice job explaining how to develop in git, but release with svn for the Acquia Cloud (then still called Acquia Hosting) by using the git-svn command. However, there is another way–conceptually simpler to me–to push code releases to your Acquia Managed- or Dev-Cloud site from git or any other VCS.
The technique described here puts your Acquia svn repository into the role of deployment mechanism rather than version control system. Your ongoing development process happens in your VCS of choice, your Acquia svn repository receives and deploys your code.
Technical notes:
- If you don’t have an existing VCS repository, using the svn repository provided by Acquia is the best and easiest way to have a seamless development-to-production workflow.
- This post assumes you can use the *nix (Linux, OS X, Unix, etc.) command line (terminal window) and that you have PERL and subversion already installed on your system.
- I'll assume that you normally create tags for the code you are releasing, though these could be as simple as specific revisions or timestamps.
When I am working, I always end up with a working copy of my code littered with .patch files, editor backups with names like foo.module~, #Untitled-6#, and files spawned from failed patches like foo.module.orig. I do not want these files to be part of my release. To avoid that, you can you have a separate, clean working copy used only for making releases. A better, more iron-clad strategy is to export your release code to an appropriately named directory. Common VCS systems support this with commands like like "svn export", "bzr export", "git archive", "hg export", and so on.
Here's an example: Let's say you have an internally accessible svn repository and the code you want to release is tagged as https://svn.example.com/website/tags/2011-03-21a. You can export to a temporary directory to using the command:
svn export https://svn.example.com/website/tags/2011-03-21a /tmp/website-2011-03-21a
In contrast, if you use git internally and have a tag named website-2011-03-21a, the command might look like this:
git archive --format=tar --prefix=website-2011-03-21a/ website-2011-03-21a | tar x -C /tmp/
or you can just make a clean local clone of your git repository like so:
cd /tmp;
git clone /home/me/projects/website website-2011-03-21a;
cd website-2011-03-21a;
git checkout website-2011-03-21a
... at which point you'd get a message about being in a "detached HEAD" state.
We will also need to take care not to get our .git, .bzr or other VCS files loaded into svn. It will make the operation much slower and could potentially expose your source code via your deployed site. The svn_load_dirs.pl PERL script automatically ignores .svn files, so you don’t need to worry about those if you are loading files from another svn checkout. The best way to handle others is just to delete the VCS files from the clean clone that you will be using with a command like “rm -rf .git”. This is all it takes to convert a git clone into a “normal” directory.
Next, you make the release, loading your exported code into the Acquia Cloud svn repository using svn_load_dirs.pl. There is a version of this script associated with each recent release branch of svn. In my experience, it's safe to use any version of this script that matches or is older than the version of the svn binary you are running locally. To install svn_load_dirs.pl, you need to export it from the Apache Software Foundation (ASF) repository and put it on your path.
For example:
svn export http://svn.apache.org/repos/asf/subversion/branches/1.5.x/contrib/client-side/svn_load_dirs/
or
svn export http://svn.apache.org/repos/asf/subversion/branches/1.6.x/contrib/client-side/svn_load_dirs/
Copy svn_load_dirs.pl.in to some place on your path as svn_load_dirs.pl. You need to edit this copy of the script around line 32 where it says "# Specify the location of the svn command.". The following change is usually sufficient, but if your subversion binary is in a non-standard location, you'll need to specify the full path:
my $svn = 'svn';
Documentation on the svn_load_dirs.pl script can be found in the online subversion book. This svn documentation refers to loading a “vendor's” release of new code into your svn repository. In this case you are the vendor and you are loading your own code release into your Acquia Cloud svn repository to deploy it. To run svn_load_dirs.pl, you will usually need to pass it your svn username and password, as well as information about the svn repository URL and what path to load the code the code into–trunk is usually where you’ll want it to go).
Now, you can push your code into the Acquia Cloud with this command:
svn_load_dirs.pl -no_user_input -svn_username XXX -svn_password YYY -tag tags/website-2011-03-21a https://svn.example.com/repo trunk website-2011-03-21a
The “-tag” argument tells the script to make the text after it a tag (marking that code push) after loading the code into the trunk path in your Acquia svn repository. Tags need to be placed under the tags/ path in your repository for you to deploy them. The -no_user_input argument makes the script answer “yes” to all questions. This is typically what you want, but you might want to run the command without it the first couple times to understand what is going on. The final argument is the path of the directory to load. It can be relative, as shown, or absolute like /tmp/website-2011-03-21a. This directory path will be used in the commit message, which is why naming the exported directory explicitly is helpful.
If your development site is on the trunk branch, your new code will be live already. Otherwise, you can now deploy to your development, staging, or production site the tag you create during the push to your Acquia Dev- or Managed Cloud site using the Acquia Network interface and hey, look! you are doing all your development in the VCS of your choice while taking advantage of Acquia’s Drupal-optimized cloud hosting infrastructure.
