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
    12·
    1 month 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·
      1 month 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

      • ilega_dh@feddit.nl
        2·
        1 month ago

        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.