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...

cross-posted from: https://lemmy.world/post/21065836

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.

  • sloppy_diffuser@sh.itjust.worksEnglish
    3·
    1 month ago

    For our lower environments we use rsync like the author but skip the pipeline altogether. The servers have a watch script to restart when files are rsynced. We then have a local watch script that rsyncs on file changes.

    Relatively instant deploy (2-5s) whenever a file is saved.

    • Oth@lemmy.zipEnglish
      2·
      1 month ago

      I frequently amaze new colleagues when I show them that deploying an update for our backend application is a sub-second affair. Our pipeline keeps track of what git tag was deployed last, diffs between that tag and the new release, and uploads the files to each of the deployment targets. It takes longer for the pipeline agent to spin up from Cold on a Monday morning, than it does to actually deploy.

      The core of the application is just php scripts, and those are either immediately up to date whenever the next call is, or swapped out the next time that component finishes a processing cycle.

      Docker containers are nice, but nothing beats the cause of a stack trace being fixed, tested and deployed to the acceptance environment within minutes of it arriving.