I started looking into Gatsby some times ago because I wanted to start writing again. After a quick test, I was really excited by the idea of using React components to write a theme for my new blog. Fortunately, I also took a step back and realized that if I needed to migrate my blog to a new engine, before I could start writing again… I would simply never write. I’m happy to announce that this blog post is not about migrating to a new platform.

On the other hand, the process I’ve used to deploy my blog has been clunky for a while now. I’m currently using Jekyll (which I mostly enjoy) so when I need to publish a new blog post, I need to build the website and upload the results somewhere. In my situation, that’s an Amazon S3 bucket while Cloudfare handles the boring parts like mapping my domain name to the bucket and providing HTTPS. For a while, the entire process was automated with Travis CI which would build and deploy my blog every time I commit onto my main branch. Then, everything started breaking and I would build and upload manually from my local computer using a couple of scripts. This was fine, but slightly more work than I was willing to do when writing a new blog post. I know I mentioned that I didn’t want to start migrating the entire thing as I wanted to start writing again, but I still took the time to dust it a bit.

First, I migrated to Jekyll 4.0, because I like having dependencies that are up-to date. The process was seamless: I bumped the gem’s version (and the one of some plugins) in my Gemfile, removed a bunch of site.baseurl macros since it’s now included when using post_url and that was it. I had a couple of custom helpers that I made to render blocks of codes and honestly I’m still baffled by the fact that they haven’t broke. Then, I moved to the latest version of ruby. Jekyll is probably the only reason why ruby is installed on my machine in the first place and that’s the reason why I let it slip. Finally, I moved my blog to Netlify.

I was already using Netlify for some side projects’ frontend and I always enjoyed how quick it was to get something running. In many ways, it reminded me of the onboarding experience we had on buddybuild. Once I granted access to my blog’s repository, I didn’t have to do anything, it automatically detected that I was using jekyll, so it filled the build command field to jekyll build and knew that the directoy to deploy would be _site. I validated those informations, played a memory game for a few minutes and my website was ready to browse.

As a final step, I bought a new domain name (romain.codes) on a whim, configured Netlify to handle the DNS and the HTTPS stuff, then migrated the old domain name from Cloudfare back to Namecheap and setup a redirection to the new URL. I ran into minor HTTPS issues where the romain-pouclet.com domain would either not load in Safari or spew a scary “This Website Is Not Secure” error, but after enough button smashing, the problem went away. The worrying part was that I’m still using romain-pouclet.com as the domain for my emails and I wanted to make sure I didn’t break that. As I’m writing this, I’m 99% sure I didn’t.

So far, everything is working great. Netlify is building my website everytime I’m pushing directly to main (like some kind of animal) or opening a pull request, which gives me a nice preview of my changes (usually a new blog post). I also installed a plugin to upload my images to Cloudinary, which is a CDN that automatically optimizes those assets. I’m not that focused on web performances (yet) but that was a low effort process to be a good citizen on the web.

Finally, since I’m still trying to illustrate my blog post when I can and when I’m inspired, I wanted to do the “meta tag dance” to get a nice preview when I share my blog post on Twitter, for example. The problem is that when I’m writing a new post and making a new illustration, the new image is not available at the main URL, so I wouldn’t be able to see what it would look like using Twitter’s Card Validator. To fix that, I used the jekyll-dotenv plugin that exposes environment variable into your themes. In my situation, I needed Netlify’s DEPLOY_URL environment variable, which contains the base url of the site where you can preview the result of a build. That way, I’m able to override the base url of the site where it matters.

Overall, I’m pretty excited that I found the motivation to write again. I don’t know how long it will last, but there are a bunch of topics that I’m excited to cover here.