Why you should automate your side project?

I am a robot

I have a few side-projects, mostly websites. They need to be maintained, the server has to be set up, new code has to be deployed. I thought automating stuff I only do once every full moon is unnecessary. This blog is the tell tale of the opposite. I decided to create a new blog around half a year ago but never had time to actually write something, or fix the design, or anything to do with it. What I did though is I automated the deploying of new blogposts, automated setting up the nginx configs, automated setting up the Lets Encrypt certificate. This means now that whenever I have time I can easily just sit down, do my thing, then deploy it with one command.

Automate server creation and deployment

Ansible server provision playbook thing

This will help when you decide to migrate your sideproject to another server. I found ansible is the most understandable tool for me, there are already a lot of playbooks for it, also you can easily modify them if you don’t like something. In the end you can just drop back to bash (but try to avoid that).
Ansible also can be used to automate deployment. Usually when you have a sideproject, like this blog, it’s a couple of files, or a java jar file, or similar. You can just write an ansible file to create the necessary directories and upload files, reload nginx, all kinds of stuff. When your project gets popular you can easily change.
Don’t forget to set up your ssh key on the servers so you don’t forget your password (and it’s more secure).

Automate development

Do you always have to start like three consoles to start the related services of your sideproject? For this blog it’s only the static site generator, but for other projects it is the db (or more dbs), node js for generating the frontend javascript, the backend server, something like play framework, or just vagrant. You can use tmux to start all services at once and keep a console on them.

Using tmux to start multiple consoles at the same time

You can use docker to contain all the necessary stuff for all of your components. This makes it portable, you don’t have to worry about accidentally deleting some crucial information which was needed to bootstrap your app (like a db schema which was in a locally installed database which got deleted on an OS reinstall).

You will not remember

There is nothing in development you only have to do once, and you will not remember how you did it last time. At least save it in a script deploy.sh.

Learn a lot

You can learn a lot by trying to understand how other types of developer/operation guys work. I always thought (and still kind of think) that server provisioning, deploying is some kind of arcane stuff, but in the end it’s all just files, processors, and memory, and…

Final world

If you don’t really have time for side projects that’s when you really have to reduce friction. Friction of development, friction of deploying. Everything. When I want to start something I want to start it immediately, not trying to figure out how I ran something half a year ago. I want to see my changes in production. I think you should always strive to do best practices when working on your own, in your free time, but you have to know when it is good enough. It depends on the goal why you are doing it. My sideprojects are mostly learning projects, therefore I strive to implement everything the best possible way I can imagine in the minute, but try not to get too caught up in this. Perfection is the enemy of done.