[hamvocke]

Good points in there. I have a little trouble with "mistake #5" though.

I found that worrying about deployment automation early on is immensely valuable, especially for side projects. I don't always find time or interest to keep working on side projects after a regular day of work. Quite often there are weeks or even months where I abandon a side project only to come back at a later point when motivation is back or things have settled down and leave more time for my side projects. If I didn't take the time to automate testing and deployments (which makes a lot of what continuous delivery is about) I find myself struggling with getting things up and running and become frustrated before I even get started.

Then there's only one way to make sure that my test and deployment automation keeps working: running it regularly, e.g. in a pipeline.

So, yes, don't over optimise your deployment pipeline early on. But having one in place early can pay off really soon -- and maybe even keep your side project alive.

[bitwisebob]

Agreed. Having a deployment pipeline in place dramatically reduces the friction of returning to an old project.

I have a back-burner project that touch very infrequently, but I can jump in, make a quick change, and have it deployed to "production" in just a few seconds.

[monksy]

This.

I'm a big fan of doing the hard work early on. When you push that step off it makes dev later slow and frustrating.

[juanuys]

I definitely automate locally by way of Makefiles, running tests then using the GCloud/aws CLI to deploy from local. Things like TravisCI, webhooks, etc come much later if at all.