Common automation approaches to build up your confidence in deploying to production.
Build tooling has become powerful and flexible enough that you can essentially do anything you want during the process. I've worked many functions, checks, and other fun ideas into builds over the years, and wanted to collect them all here for your inspiration.
Before we get into the list, there are a few clarifications I should make.
Almost every example in the list could be taken to an extreme. This list is really just getting you started. You have to decide the extreme to use for your site.
There are a number of actions that are core to the continuous integration, delivery, and deployment that has been around for years, including:
What I've included in the list below is aimed more at tasks you may not commonly associate with automation or your build process. But automating these tasks can save you a ton of time, reduce friction in your publishing process, and make you more productive.
Here are a number of tasks that I've automated over the years, many of which I continue to use for the time and hassle they save me. (This list is is no particular order.)
In most of these cases, I have not prescribed a specific method for achieving the result. This is dependent on the service and/or languages that you're using.
When I discovered that you could automate broken links, it changed my life. I can now publish with the confidence that I am not deploying content with broken internal links that would result in a 404 not found error.
Note that many of the tools that can help you achieve this will support the ability to determine whether to check both internal and external links. Personally, I tend to not test external links. They slow down the build significantly and aren't as crucial to the continuity of the reading experience on this site.
Alternatively, I've considered running a period check for all links to catch broken external links as well.
There are a wide range of a11y tests you can run against your site. But even if you aren't comprehensive, a few small tests — e.g. finding missing
alt attributes on images — can go a long way in helping more people access your content.
You can check if code is formatted according to some set of rules (Prettier, ESLint, Stylelint, etc.) and choose to fail the build if it is not.
Some of the tools (like Prettier) also allow for automatically formatting code and saving the result. If you do this, you probably also want to ensure you've run the appropriate checks after that automated commit, to ensure nothing was broken in the process.
A fairly common case is to generate a sitemap from the pages in your site at build time. It's nice to set this up once, forget about it, and have confidence that search engines can find your content.
On a similar note, you can check all your content to ensure that every page contains the appropriate SEO fields — title, image, description, and anything else you'd like to include.
This is one that I built myself that I totally love. It automatically generates meta images for every piece of content that doesn't already have one. It then uploads them to S3 and adds the appropriate image URL to the content object.
Many services will let you run tasks after the build has completed. You may want to send a notification, commit changes to your repository, or do a number of other tasks. One thing I've done is automatically publish tweets after successfully completing builds with new blog posts.
Although it may be less likely that your users are sensitive to colorful language, what is absolutely more useful is checking for misspelled words.
The really nice thing about this type of check is that you can run it without building the code. The downside is that you generally have to feed the system a lot of words to skip because it'll check the code (depending on how you've configured it).
It takes a long time to test page speed performance. But you can run a performance check on your home page on every build. And you could choose to run a more comprehensive test on a less regular basis, similar to the suggestion on checking for bad external links.
Depending how your CSS is bundled, you may benefit from inlining critical CSS. Again, this is time-consuming and may best benefit your highest-trafficked pages, as it can speed up initial page load significantly.
This list is certainly just the beginning. I'm sure there are many more tasks you could automate during your build.
I'd love to learn what they are. If you have any ideas for this list, send me a message.
Manually creating images for blog posts can be super time-consuming. Here's the foundation necessary for automatically generating meta images for content in markdown files.
This is the (custom) workflow I use to automatically tweet after publishing new content to my blog.
Although more applicable to traditionally-built sites, inlining critical CSS can be a quick and easy performance boost for your site, especially as it grows.