This post describes my lessons learned after 10 years running production environments in sizes ranging from "just getting started" to a "Series F" company wi...
Hi friends, as promised, I'm back with my second post. I'll be hanging around in the comments for any questions!
In this post, I take a look at a typical deployment process, how long each part of it takes, and then I present a simple alternative that I use which is much faster and perfect for hobbit software.
So it really is that simple: a small bash script, building locally, rsync'ing the changes, and restarting the service. It's just the bare essentials of a deployment. That's how I deploy in 10 seconds.
I'm strongly opposed to local builds on any semi-important or semi-complex production product or system.
Tagged CI release builds give you a lot of important guarantees involved in release concerns.
I'll take the fresh checkout and release build time cost for those consistency and versioned source state guarantees.
I would imagine you could run into an issue like this building off an M1 or newer Mac and deploying to a Linux based env. We've run into a bit of an adjustment with our docker image builds where we need to set the buildarch or else it fails to deploy.
Our build times aren't blazingly fast, typically around 4 minutes for npm/yarn build for frontend apps and loading the data to the image and any other extras like composer installs. Best time saving for us was doing a base image for all the dependency junk that we do a nightly on
This was exactly the problem in my last environment. I was the second dev and two more were onboarded after me, but everyone had issues replicating the original dev’s local environment in order to deploy.
First thing I did was set up a basic gitops pipeline. Worked like a charm.