Beyond Code: Crafting DevEx Journeys
In the dynamic realm of software development, where every keystroke contributes to the creation of innovative solutions, the experience of developers plays a
As a new project, I was assigned the task to automate internal processes for our website deployment and to implement some features. Therefore, I had to deal with the topics Jekyll, GitLab Runner and AWS S3 Buckets.
GitLab offers a continuous integration service which is easy to configure. You just need to add a .gitlab-ci.yml file to the root directory of your repository and configure a GitLab Runner within your project. Now, because of the Runner, every commit or push, triggers the CI pipeline. In the .gitlab-ci.yml file you can configure what the GitLab Runner should do. For example, you can tell the GitLab Runner to execute a script:
In our case, we wanted to push code to the repository and the Runner should find out if we are working on the master branch or on a feature branch. If we are on master branch, it should do the production deployment of our static website. But if we’re working on a feature branch, it should deploy the code to our staging environment, using a particular URL. To accomplish this, I needed to change some things in our Jekyll configuration.
Jekyll is a simple, blog-aware, static site generator that renders Markdown, Textile and Liquid templates, and produces a complete, static website ready to be served by a webserver. In the config.yml file, the so called baseurl option has to be changed to the name of the branch within every deployment. So let’s pretend, I have the website http://miriamgrainer.com and I’m working on the branch example. When I push code to my repo, I would like to have “example” as my baseurl: http://miriamgrainer.com/example
To achieve this, you can do something like this in your _config.yml file: baseurl: /example. The problem here was, that we didn’t want to change the variable manually for every deployment. So, we wrote a script that changes the value of baesurl to the name of the branch, or leave it blank if we’re on master.
If we’re deploying to the staging environment, the GitLab Runner has first to create a subfolder, named after the branch, and you also have to tell Jekyll to create the website in this directory. Otherwise, you would not see any content when you call your site with the baseurl option. Our static website lives on AWS S3 Buckets, because we use s3_website to deploy. Therefore, we have a s3_website.yml file were the destination buckets are defined. Here you have the variable ‘site’ with the path were the website is generated. Another challenge occurred, when I wanted to have multiple branches deployed. Every time when a branch was deployed to the bucket, the deployment before was deleted. You can easily fix this with one line in your s3_website.yml file: ignore_on_server: _DELETE_NOTHING_ON_THE_S3_BUCKET_.
Without the help of my colleagues Edmund and Jürgen, I would have solved some problems in a more complicated fashion that was required. In my opinion it’s a big benefit to work in a small group, because you can work and solve problems easier together. We also had some discussions about how and why things work like this. That helped me a lot and I learned some real cool new stuff.
You are interested in our courses or you simply have a question that needs answering? You can contact us at anytime! We will do our best to answer all your questions.Contact us