By alexmoreno, 11 July, 2020

(or AWS, or Digital Ocean, or...)

If you’ve been following my mumbling on twitter you may already know I have been trying to find a better workflow for my blog. I want something that loads fast for my users, but also something that I do not have to spend a lot of time maintaining.

Static generators like Gatsby, Nextjs, React, Vuejs and the likes are great, but for now I did not want to introduce a lot of complexity while I explore possible solutions. I want an easy workflow that I can jump on easily after a few days (or weeks) without touching the blog and know that it’s simple enough that I won’t have to go through notes to remember how I was deploying this (my attempt at Kubernetes for a personal site, although instructive and fun, it was definitely an overkill).

I did already know the excellent job Mortensen was dedicating to his Tome module, and gave it a few tries before. Where I was a bit stuck and not 100% convinced was with the build process. See how I was doing it.

My old ”build all the things” way

  • Build your content locally,
  • Push to Netlify ,
  • Execute the builds in there:
    • composer install && ./vendor/bin/drush tome:install -y && ./vendor/bin/drush tome:static -l $DEPLOY_PRIME_URL
    • Your static content is deployed to an html where Netlify will serve it from 

This meant that pretty much every small change in my blog, regardless if it was a new post, fixing a typo or adding a new batch of views, was requiring a full build in Netlify. Each build at this point was surpassing already the 30 minutes, and was making Netlify to fail because… well, the free tier does not give you more than those 30 minutes. Fair enough that they even give that for free to be honest.

And, full disclosure, building in the CI is the good practice. It ensure that your site is fully functional and you are not breaking anything.

However, give the limitation on build time, and that this is a personal blog where I should not spend too much time maintaining, I think I found a better way.

 

My “build on site” new way

Using ddev you can have a machine ready in your repo to pull, make changes and push back to the repo. And when I say DDEV I mean Lando with ADS if you require more complex setup with BLT, DrupalVM, bare metal, … you get the point of choose your own potion.

And actually on my case I have ”bare metal, one extra step in the middle with a dedicated cheap workstation that I acquired a few months back for a 100 pounds. That’s not really needed for this but I’ll talk about that on a future article.

So, coming back to the build, this is my final workflow (drum roll here):

  • [OPTIONAL] ddev start, drush uli, etc (if you have the MV or your docker containers stopped)
  • Create your content, make changes on your site, etc
  • Export it with Tome:
    • ddev exec drush tome:export
    • ddev exec drush tome:static --uri=http://alexmoreno.net
  • Push to Netlify (or aws, digital ocean, bare metal, ...)

Note the uri. Using that you ensure that your local images and files are translated into proper production urls. Given you don’t have a remote server you can’t really play with your settings to differentiate between local and prod, but that’s the uri argument purpose in tome:static.

All you need now is configure your Netlify to:

  1. Point to your git repository (github, gitlab, bitbucket, …)
  2. Tell Netlify to build your artefact from the html folder that tome has created
  3. Enjoy your shiny site in prod.

Netlify with Tome and Drupal workflow

Netlify with Drupal and Tome workflow

The only inconvenient that I found on this workflow is that I’d normally add a step 2.1. Enjoy a nice cap of tea… however on my case the build takes less than 30 seconds, so I can’t properly brew a tea the way a like it on that time :-D

Another thing I really like about this workflow is that if your build produces unexpected results and you end up breaking production, you could simply:

Go back in git to a previous version of your html and push back to the repository, Even simpler, select your previous build in Netlify and deploy instead of the current broken one.  

Image: deploy old build

Deploy old build

Conclusion

That’s pretty much it. Depending on your theme you’ll have to ensure you don’t have links to login, comment, etc, as your site is not anymore a Drupal dinamic site in prod (although proudly powered by Drupal one).

To sum up, some of the advantages of this setup:

Advantages     - Simpler setup in Netlify      - Faster deployments (from more than 20 minutes, to around 50 seconds)     - Easily could move to another provider, Say aws, digitalocean… or even your own server.     - More secure. If I don’t have the time to upgrade in the case of a module or core security upgrade, my Drupal site is safely behind a local network with as many (or few) security protocols as I want (or simply keep it disconnected).

And the disadvantages that I found:

  • No time for tea
  • No dynamic content (contact forms, comments, etc…)
  • In bigger environments, you should re-build on CI. Otherwise you could find your site broken too late

 

The first one can be a big deal or not (it is for me, but hey!). For the she second one I want to explore options. Maybe that’s just moving to GatsbyJS/NextJS, whatever, be it partly or fully. But the important thing, I have a beautiful workflow that works and will keep me busy writing, maybe about how to add dynamic content :-).

That’s it. Find me on twitter or LinkedIn if you want to drop me any messages about this :-)  

Tags