Continuous Integration for Website Deployments
A deployment—when you take a new website or a change to an existing website and put it on a live server so people can view it— is not as simple as just uploading some files. There might be code, images, or config settings that have to be moved up. You might have to clear some caches or make sure domains point to where they should. The list goes on.
Continuous integration allows all those things to happen automatically every single time. Whenever you commit your changes to version control, it runs virtually all of your steps short of going live. That means it verifies things like: Did the files generate? Did the settings merge correctly? Does the code meet standards? If nothing gets flagged, you know your setup is deployable. All those things got checked without you having to lift a finger.
Continuous integration has become more and more popular and is, in fact, the de facto way to do deployments now.
What are some best practices for deploying Drupal Commerce websites?
- Run automated tests. There are a bunch that come with Drupal, and you should run at least some, if not all of them, particularly when going live with a new site. It can take a few hours, but it's totally worth it.
- Run code standards. There's a PHP code standards plugin that checks your code against a specific set of Drupal code standards. This keeps your code nice and easy to work with. And even if you have code that fails, the fixes are generally quick and easy, and once you've dealt with them you can rest assured that you have consistency of code.
- Run "Composer install" and any of your build commands on your build server, not the live server. You want to have all the files needed to make the site so you can do as much as possible on the build server before sending it live. You should be doing almost nothing on your live server, except maybe flushing the caches afterward.
Why are some people NOT doing continuous integration?
It takes a bit of effort to get it set up initially and to figure out how it all works, and some people just figure it seems too hard, so they don't bother. But once you set it up, you will never NOT do it, because it is awesome.
If we want to do a full deployment of a new setup, we take the branch that we're working on and we merge it into the master. That is the only step that has to be done manually. Everything else is done automatically. If there are 10 steps that have to be done, you just put them in the config file once, and you know they all get done every time.
And if they do fail, the deployment will stop, and you'll get an email. You can even set it up so that if the deployment stops at a certain point, it will roll back.
Continuous integration is great for:
- Simple but urgent fixes. If you're in a rush, you just have to do that one change, commit it, and boom, it all updates.
- Complex deployments. If you're pushing stuff to a database server and a file server and four different web servers and a caching server, you can set the job up once and it will all get done automatically each time.
- A newbie covering an emergency fix. Say the normal project team is out sick, and there's some urgent fix that has to go out right now. With continuous integration, the newbie doesn't have to read through a bunch of instructions to figure out how to do the deployment. All they have to do is commit the one change, and all the updates happen exactly the way they should happen.
Using continuous integration can actually make deployments faster, with less downtime. The window of time that the live site is unusable or unsynced is about as small as it could possibly be.
TL:DR - Deployments are so much smoother with continuous integration, and once you start using it you'll never stop.
More from Acro Media
- High Five video: Automated Drupal Code Testing: What, Why and When To Do It
- High Five video: How to Ensure Your Website is Stable
- Drupal Commerce 2: A Technical Overview
- Learn more about Acro Media
Continuous integration for all of our clients
We use a continuous integration deployment strategy with all of our Drupal Commerce client projects, making sure that the code is clean and any downtime is minimised. Is this something you'd like to explore?