Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Gitlab CI and SilverStripe


Published on

Slides by Hayden Shaw and Tim Oliver of E2 Digital about continuous integration (CI). Delivered at a SilverStripe Meetup in Christchurch on August 1, 2018.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Gitlab CI and SilverStripe

  1. 1. Gitlab CI and SilverStripe E2 Digital Hayden Shaw Tim Oliver -
  2. 2. Who are we? E2 Digital is a full service digital agency who are all about doing digital smarter so our clients do business better. SilverStripe has been our CMS of choice for the past 3 years.
  3. 3. Once upon a time “Okay I need to make a change to this website, how?” “Edit the files on the server”
  4. 4. Once upon a time “Okay I need to make a change to this website, how?” “Check out the files from source control, make changes, use FTP”
  5. 5. Once upon a time “Okay I need to make a change to this website, how?” “Check out the files from source control, make changes, run SASS, rsync files up”
  6. 6. Once upon a time “Okay I need to make a change to this website, how?” “Check out the files from source control, build your local dev instance make changes, oh but don’t run sass yourself, there’s yarn, gulp, bower, webpack, babel, and you can’t deploy directly since it’s behind a load balancer and ...” (see How It Feels To Learn Javascript In 2016)
  7. 7. What is CI? Continuous Integration is a software development practice in which you automatically build and test software every time a developer pushes code to a project.
  8. 8. How are we using Gitlab CI at E2 Digital? ● Build our frontend assets and store them as artifacts to be used in the deploy stages ● Deploy to staging environment on commits to master ● Create a release branch when the repository is tagged and deploy to a UAT environment on the SilverStripe Platform
  9. 9. An aside - SilverStripe Platform ● CWP hosting equivalent in the private sector ● Fully managed by SilverStripe - so you can avoid the distractions of infrastructure setup and ongoing support ● Deployments made easy ● On AWS ● Autoscaling ● No direct access to servers
  10. 10. Assets - why a release branch? ● When using SASS we don’t want to commit the compiled CSS and other build artifacts to git ● But we have to deploy to the Silverstripe Platform using git! ● So the compilation has to happen somewhere ● We use Gitlab CI to commit assets to separate branches when we tag a release, and deploy that ● (There are other options here depending on your host)
  11. 11. gitlab-ci.yml Just a YAML file in the repo root. Special tag: image The docker image to use you can generate a custom one with your own requirements via Dockerhub
  12. 12. gitlab-ci.yml Special tag: stages You can customise these, but these three are the default
  13. 13. gitlab-ci.yml Special tag: before_script Set up any dependencies you need across all jobs.
  14. 14. gitlab-ci.yml An actual job: build_assets The only required element is script: These are the actual commands to run on the docker instance.
  15. 15. gitlab-ci.yml More jobs only: tag lets you run jobs for specific git branches Here we deploy master to a dev server and 1.2.3 tags to the SS platform
  16. 16. Demo
  17. 17. The agency advantage ● CI ensures your stuff can be built. No surprise local dependencies. ● This is particularly good from an agency point of view. The project model often means doing heavy development then leaving a site alone for a year - getting started again at that point with staff turnover and technical stack changes can be pain.
  18. 18. Caveats ● Adds turnaround time if you’re waiting for builds for any reason. Cached runners help, so does optimising your docker images. ● Document what’s happening on your Gitlab projects ● Experimenting with CI can be fiddly since you’re pushing commits to gitlab to see the behaviour ● Limited free runner time - plan for this running out once you have multiple projects.
  19. 19. Tricks ● Test CI changes on a branch since you can set a block to run for a particular branch name only - fiddly when you’re doing logic on branch name though ● Private CI vars let you handle all the site-specific credential and keys ● CI_DEBUG_TRACE ● Slack hooks for CI failures ● Custom docker containers to reduce dependency installation
  20. 20. Where next? ● Add more things to the pipelines ○ ZAP security scanning ○ Performance testing ○ More linting ● Investigate Gitlab Auto Devops
  21. 21. Useful resources • - Gitlab CI Docs • - Validate your .gitlab-ci.yml • - SSP API docs