Continuous delivery workflow: Build script for PHP Composer (Drupal) on Docker

Question

I'd like to set up a continuous delivery workflow for our new Drupal site. When someone pushes to our Git repo (typically) master branch, a build job on our CI server is triggered. This job will check out the source code, import the database from production, and build the Drupal project running in a Docker container.

I'm now looking to create the actual script that the CI job will run. I come from a Jenkins background, and there one would create a Jenkinsfile for this. We're probably not going to be using Jenkins for this project, so I'm looking for a tool that can be run regardless of the build server.

The most straight forward way would probably be to script this build using bash or python or something. I'm quite new to both Drupal and PHP, so I'm wondering if there are any tools out there similar to Jenkinsfile I can make use of, which I can run on Gitlab or whatever other CI server we go for?

Answer 1

Each CI/CD system is different when it comes to performing the job(s) that the execution pipeline consists of. In most (if not all) cases the details are part of a configuration which is specific to the particular CI/CD system used. As you mentioned Jenkins uses a Jenkinsfile, GitLabCI uses .gitlab-ci.yml, others use "live"/GUI-based configurations, etc.

So I don't think you can find a common solution directly pluggable in an arbitrary CI/CD system. But you can get close to that: fundamentally each of these configurations are simply adaptation layers between the CI/CD system and the automated task(s) to be performed.

So if you can create a (set of) standalone script(s) to perform your automated step(s) in as portable way you need as possible you should be able to integrate with in almost any CI/CD system without too much trouble: any decent CI/CD system should support a custom script invocation mode to cover for whatever special case that doesn't properly fit into its pre-defined cases.

Using python/bash is generally quite portable, up to you to decide if that indeed covers all possible execution environments you'd be willing to consider.

I'd recommend structuring such script itself as a wrapper around smaller scripts implementing its logical/functional steps - some CI systems may require individual control of the steps or may offer advantages if such control is provided. In your case I'd have separate scripts for:

• checking out the source code
• importing the database from production
• building the Drupal project running in a Docker container (maybe this can/should be further split if it makes sense?)

And I'd add a wrapper script tying them together for one-shot end-to-end execution, either by CI/CD systems not interested in the individual steps or even for manual invocation.