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.

  • Max-P@lemmy.max-p.me
    6·
    11 days ago

    Also, series F but they’re only deploying on one server? Try scaling that to a real deployment (200+ servers) with millions of requests going through and see how well that goes.

    And also no way their process passes ISO/SOC 2/PCI certifications. CI/CD isn’t just “make do things”, it’s also the process, the logs, all the checks done, mandatory peer reviews. You can’t just deploy without the audit logs of who pushed what when and who approved it.

    • BatmanAoD@programming.dev
      6·
      11 days ago

      You’re not wrong, but not everything needs to scale to 200+ servers (…arguably almost nothing does), and I’ve actually seen middle managers assume that a product needs that kind of scale when in fact the product was fundamentally not targeting a large enough market for that.

      Similarly, not everything needs certifications, but of course if you do need them there’s absolutely no getting around it.

      • something_random_tho@lemmy.worldOP
        3·
        11 days ago

        For sure, in PCI environments this doesn’t work. And in the Series F company we don’t use this approach for that very reason. But there’s tons of companies that don’t have or need external certifications, and it works for that much more common scenario. For the small web (i.e. most of the web), it’s ideal.

        The important takeaway isn’t “wow, doing production builds on your PC isn’t secure.” Do it on a dedicated box in production, then. The important takeaway is there’s a mountain of slow things (GitHub workers, docker caching, etc) which slow developer velocity, and we should design systems and processes which remove or eliminate those pains.