In our previous post, Tim Oliver gave us an introduction to GitLab CI and how we use it at E2 Digital to manage our deployments. Below, I’ll delve deeper into how we use it, specifically around our SilverStripe Platform deployments.
We signed up to SilverStripe Platform back in March 2016, not long after SilverStripe announced the Stack Share feature. Amongst other benefits for agencies, Stack Share is highly desirable as it allows you to run multiple websites on a single SilverStripe Platform stack which we’ve found to be a far more cost-effective solution for our smaller clients.
Long before wrapping our heads around continuous integration (CI), SilverStripe Platform was helping us streamline deployments by eliminating infrastructure distractions and making sure we no longer had to worry about frightening manual rsync commands.
Get started automating your deployments
The following .gitlab-ci.yml snippet will look familiar if you read our previous post. However, here we’re creating a release branch containing our build assets (which now can be superseded by package deployments) and running a shell script at the end to initiate a SilverStripe Platform deployment via the provided Deploynaut API. The API conforms to JSON API specifications and, should you get stuck, the docs contain helpful example URIs.
The likes ofGITLAB_PRIVATE_KEY
,GITLAB_REPO
, andPLATFORM_PROJECT
are all unique CI / CD variables stored against individual GitLab repositories.
Let’s now investigate the deployment shell script which is where the magic happens.
At the top of script, we’re simply defining some variables. To touch on a few important ones:
- The likes of
PROJECT
,ENVIRO
, andCOMMIT_REF
are arguments that have parsed in from our .gitlab-ci.yml file. TOKEN
is your API token which you can generate from the SilverStripe Platform dashboard.PLATFORM
is the address we’re going to be making our API requests to.
The next step is to queue a new ‘fetch’ on our repository through the Deploynaut API which is exactly what you need to do when deploying via the Dashboard.
Once that’s run, we can move onto building up a deploy file which will form the request body of our deployment API request. In the request body, we need to include things such as ‘ref’ and ‘ref-type’ which relate to the commit we’re deploying, but we can also update the ‘title’ and ‘summary’ of this deployment, and even bypass approval.
From there, it’s simply a matter of triggering the deployment via the Deploynaut API and waiting for it to complete.
At the Silverstripe Platform end, this will show up in the deploy log and then your site will update with the expected changes.
At E2 Digital, we currently only use this automated method for UAT deployments. Once we’re happy with the deployment, we manually promote the UAT to production. However, this is an area that will depend on your desired production workflow.
What next?
You can find the deploy script and the rest of an example CI setup at ci-example.
If you have any questions, comments, or feedback about this setup, feel free to reach out to us on the SilverStripe community Slack (@thats4shaw or @xyphoid).
More like this, straight to your inbox
Click here to subscribe for regular updates from the SilverStripe Community.
Post your comment
Comments
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments