Skip to content
DevMeme
2430 of 7590
Deployment Post #2701 · source on Telegram

The galaxy brain guide to software deployment

Description

An 'expanding brain' meme format with four panels, each depicting a progressively more chaotic and reckless method of deploying code. The first panel, with a small brain, describes the ideal 'seamless transfer from tested development branch to production environment.' The second shows a slightly more illuminated brain for 'pushing tested code to production via git push origin master.' The third, with a brightly glowing brain, is 'testing on production, via git push origin master.' The final panel, representing the 'galaxy brain' state of enlightenment, is 'writing code on the production server via ssh and vim/nano, then pushing to git from the production environment.' This meme satirizes the spectrum of deployment anti-patterns, from common shortcuts to the most terrifying 'cowboy coding' practices. For senior developers, it's a painfully relatable progression of how development standards can decay under pressure, leading to the ultimate sin of editing live production code

Comments

20
Anonymous ★ Top Pick The final panel isn't a deployment strategy; it's a live-action role-play of the CAP theorem where you sacrifice both consistency and availability for the partition tolerance of your own sanity
  1. Anonymous ★ Top Pick

    The final panel isn't a deployment strategy; it's a live-action role-play of the CAP theorem where you sacrifice both consistency and availability for the partition tolerance of your own sanity

  2. Anonymous

    DevOps nirvana: ssh into prod, hot-patch in vim, :wq, git commit -m "tested in revenue", and let the post-commit hook page yourself - true closed-loop observability

  3. Anonymous

    The only thing more enlightened than editing directly on production is realizing you've been doing it on the wrong server cluster for the past hour while the actual production server has been serving cached 404s

  4. Anonymous

    The final panel perfectly captures that 3 AM moment when you SSH into production, fire up vi because vim isn't installed, make a 'quick fix,' then realize you need to commit it to git to maintain the illusion of version control - essentially using production as your development environment and git as a backup tool rather than the other way around. It's the deployment equivalent of putting the cart before the horse, then realizing the horse is actually a database server and the cart is on fire

  5. Anonymous

    Reverse GitOps: the source of truth is whichever prod box you SSH’d into at 3 a.m

  6. Anonymous

    Our GitOps strategy is eventual consistency: prod is the source of truth, Git is the read replica we backfill after Vim over SSH

  7. Anonymous

    Vim in prod isn't cowboy coding - it's the architect's final form: zero context switches, infinite regret

  8. @APT3M 5y

    You can use ssh extensions for vs code or idea, really comfortable for coding on production😏

    1. Deleted Account 5y

      why would you want to use vscode?

      1. @UQuark 5y

        Because it's pretty handy for such languages as Go, Python or C Of course, for Java/C#/other languages with powerful SDK you have to use a specific IDE

        1. Deleted Account 5y

          why would you not just use vim tho?

          1. @UQuark 5y

            Because I don't know how to exit vim

            1. Deleted Account 5y

              good

              1. Deleted Account 5y

                never exit vim

                1. @x_Arthur_x 5y

                  You don't have to if you never enter it

                2. @gizlu 5y

                  Just install emacs

                  1. Deleted Account 5y

                    god motherfucking damn

                    1. Deleted Account 5y

                      another instance of editor war

    2. Deleted Account 5y

      Ssh extension for vscode. God help us

  9. @UQuark 5y

    And also, IntelliSence

Use J and K for navigation