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.

  • Kissaki@programming.devEnglish
    11·
    16 hours ago

    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.

    • radau@lemmy.dbzer0.comEnglish
      2·
      9 hours ago

      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