Automation makes your life easier

The static website is up and running, now it is time to make things a little bit more convenient updating it and publishing new content.

In my last post, I explained why I set things up based on managed infrastructure. This time, it is more about how to make this setup more usable by automating some of the publishing steps. You may ask if it really makes sense to automate copying static content to an S3 bucket, and this question is absolutely valid. The answer is, guess what… it depends. It depends on how often, how do you edit the content, how much fun is it to implement it, …

In the end, my opinion on the topic is: If you can automate repetetive tasks, you should do so.

Current flow

Maybe this helps to understand, why it makes sense to automate even small tasks like this, to just get rid of them.

This is the basic flow for each change of the page:

Not difficult, but if you have to do it for every change, for every typo? Think about how much time this will consume.

And this is currently a really simple setup. Thinking a little bit into the future, maybe I want to have a staging environment, just to be sure, everything works fine. Then it becomes even more annoying.

The Target Solution

My website is build with Jekyll, which means I need to have some preconditions installed in order to build the actual static content from a bunch of Markdown files, layouts, and other assets. This alone would be a good reason to use a CI/CD pipeline. With the manual release process described above, it makes even more sense.

So, what I do, on a very high level is this:

Having a local dev environment

As I said, I am an engineer and like to work with my IDE. So, managing the content of my website just like a development project comes quite natural to me.

In my local environment, I have all the prerequisites installed, that I need to work on the content of my page and to have proper preview. AS soon as I am done with my changes, it will commit and push to my code repository at GitLab.

In terms of changing the page content, this is it. The rest will happen automagically.

GitLab as code repository and CI/CD pipeline

I am a GitLab guy. And to be honest, this is nothing I would like to discuss here. Conceptually, the whole flow would work the same way, if I would use GitHub, or Bitbucket, or whatever else code repository + pipeline driver combination. It is just that I am used to store my code there for years, now.

This is, what they offer for me:

• Proven to work code repository
• Easy to use branching
• Shared runners for your build pipeline
• Some free build minutes that I can use to build and deploy my page
• And maaaaany other things, I do not use for this. (I know, Darwin)

What I do, in the end is quite trivial. I have a two step pipeline.

• Step one will build the page with Jekyll and pass the result to step two
• Steo two will sync the page with the content of the S3 bucket and then invalidate the CloudFront cache, making the changes available immediately

Each step spins up a runner based on a container image that will be suitable for the job.

Step one will use ruby:3.1.3and step two will use registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest.

Website deployment with automation

So now, after I implemented the changes, the overall flow looks like this:

Much better, isn’t it?

No more manual interaction with AWS console at all.

Just make a change and push it to GitLab… That’s it.

Summary and Conclusion

With a little effort I was able to set up an environment that relieves me from manual deployments. Now it is easy and seamless to deploy the changes to my static website to “production”.

Was it worth the effort? Yes, I think so

Is it a perfect solution? Probably not, but good enough… for my purpose

Finally, this is not meant to explain the automation of my website or discuss wether it makes sense or not. The point of this post is this:

If you can automate repetitive tasks, you should do it. Be it on a large scale project, building and deploying complext applications or on projects like mine which is neither large nor complex.
The concepts and principles are the same and build the foundation of a DevOps mentality, which is key, if you want to become a more agile organization.

Thanks for reading!