

Posted in
May 22, 2018
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.
You should:
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.
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 the consistency of code.
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.
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 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 rollback.
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.
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 minimized. Is this something you'd like to explore?