The goal of automating deployment is to make introducing new features easier. In this post we will learn how to set up a workflow that will move code and configuration of your drupal site from your local development station, to development, to staging and to production all by a using your version control and a push of a button.

Why Automatic deployment

Its faster. Deploying automatically or semi automatically is a lot faster. You dont need to transfer the database settings manualy. You dont need to transfer the code manualy. You dont have to set the settings correctly on production or staging.

Its less error prone. A process that is automated and executed every time is less likely to contain errors.

Its well documented. An automated process almost always involves some kind of script being executed. This script is in version control. You can see how it evolves and why is became like it is.

Reproducable. The process can be reproduced. You know exactly what has happend to the site.

History. You can have a complete history of all the builds.

Continous integration. Automating deployment brings us also closer to CI. Being able to introduce changes automatically and test them automatically reduces regression and makes you sleep better at night.

Dev - staging - production
On your server create three folders where jenkins will able to build into. For example:

/var/www/ddcdemo.dev

/var/www/ddcdemo.staging

/var/www/ddcdemo.production

Create vhosts on the server connecting to these folder so you sites are accessible. We use dummy urls but mostly it will be real ones. (We put and entry in our /etc/hosts locally to be able to see the sites on ddcdemo.dev, ddcdemo.staging, ddcdemo.prod)

Automate the workflowExporting database changes
To use continous integration with drupal and to work in team in general you cannot make database changes on the environments. This will not only be very error prone, you might forget something when deploying your feature, it is uncontrolable.

The features module allows us to export drupal configuration (code) into files. for example it will make a representation of a view and export that into a file. This file can be committed into the repository and deployed in a controled way. (http://drupal.org/project/features)

What you cant deploy with features should be done with hook_update(). You can code the database change in this hook and the drush updb command in the deploy script will execute all hook updates and you change will be deployed.

//Hook update example

Configuring jenkins jobs
First we will create a job per environment. Then we will create one or more testbot jobs. This way we will be able to deploy our new code to each environment. Jenkins will always connect to a repository and do a checkout of the code in a workspace. We will then sync these workspace directories with our folders

Now we have to share the feature with our team mates and have it tested in our CI. We have to push the code so we can check it out in our testbot job to test our feature.

git flow feature publish news

You can now use the jenkins job to deploy the code of the feature branch. Type in the branch field "origin/feature/news" Fix tests if needed.

To stop developing on the feature

git flow feature finish news
git push origin develop

Now git flow has merged all our work into the develop branch. After we push it to the origin. Our CI system should now be able to detect the change and automatically execute our develop build. The code that was merged into develop will now be deployed on our development environment and tested.

Note: You can also run tests locally but simpletest is pretty slow so practically it is better to let the server handle it. There are some optimisation that can be done but they are beyond the scope of this post.

If any tests are failing we should fix them.

Release
Now we need to create a release to deploy on our staging environment so our client is able to test it.

git flow release start v0.1.2

When we are done adding to our release branch we can push it remote and use it as a branch to deploy on staging.

git flow release publish v0.1.2

Now in Jenkins we can fill in our branch name in our staging job and get that tested. If all goes well we can finish our release branch and it will be merged in both the master and the develop branch

git flow release finish v0.1.2
git push origin master

We can keep track of the version by storing this in a text file in the root of the project.

Now we should be ready to deploy the master branch on our production environment. Lets execute our production job. Note that no tests are executed. We did all the testing on our other environments. We are using the contributed simpletest module and the remotetestcase which allows us execute tests directly onto the database so we dont need to do complex setups. But a disadvantages is that it pollutes the database with test content.

Hotfix
Create hotfix branch - v0.1.2.1

git flow hotfix start v0.1.2.1

Finish the hotfix branch. This will merge the change into develop and the master. Push the master to the central repository. Push the production job and the fix is on production.

Conclusion
What we have now is a powerful way of deploying code in a controlled way. When developing proper tests for each feature we will be able to minimize regression and we are able to release automatically in a controlled way.

Add new comment

Your name

E-mail

The content of this field is kept private and will not be shown publicly.