Rolling, rolling, rolling back nothing I love more than communicating why we had to roll back again (⁠ノ⁠ಠ⁠益⁠ಠ⁠)⁠ノ

  • ComfortableRaspberry@feddit.orgOP
    link
    fedilink
    arrow-up
    21
    ·
    edit-2
    23 hours ago

    It’s internal development (Portugal) developing something for an internal department (Germany). There’s nothing professional going on here so we are far from any ci/cd pipeline. One person can change everything, because it’s just two developers (1 frontend, 1 backend).

    Plus things are busy and we (team in Germany) are way more interested in this thing working well than they (team in Portugal) are since they have higher priority tasks…

    Of course I can say fuck it and live with the poor quality caused by circumstances that were partially caused by poor management decisions of the company but I’m not able to care little enough.

    • surewhynotlem@lemmy.world
      link
      fedilink
      arrow-up
      10
      ·
      20 hours ago

      I demand CI/CD for my scripts. If it runs in prod or against prod or anywhere near prod, it gets a pipeline.

      Technical maturity isn’t just for big companies and important things. It’s a practice. Why half-ass something when you could whole ass it?

    • JackLSauce@lemmy.world
      link
      fedilink
      English
      arrow-up
      17
      arrow-down
      1
      ·
      23 hours ago

      Pre-commit hooks don’t require a pipeline nor any money. In most cases it’s one line of code to make the tests run every commit

        • kkj@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          19
          ·
          22 hours ago

          Fix your shit and it won’t stop you from committing.

          It’s also usually only on certain branches, so you can make a branch where you break things and then fix them before you merge to testing/main/whatever.

          • SandmanXC@lemmy.world
            link
            fedilink
            arrow-up
            6
            ·
            21 hours ago

            TIL precommit hooks can be set per branch. I was being facetious to begin with but this sounds pretty good actually.

            • kkj@lemmy.dbzer0.com
              link
              fedilink
              English
              arrow-up
              2
              ·
              19 hours ago

              What do you do if you have code that isn’t complete enough to work? Do you have to just leave it untracked?

              • chellomere@lemmy.world
                link
                fedilink
                arrow-up
                1
                ·
                16 hours ago

                I don’t know what others do, but I personally whip out git commit -n and bypass the hooks in this situation.

              • neonred@lemmy.world
                link
                fedilink
                arrow-up
                2
                arrow-down
                1
                ·
                18 hours ago

                If you have code that is not complete it is not qualified to be deployed. Cut work items into smaller chunks but never deploy not fully, 100% working and tested stuff. Not even on dev.

                • kkj@lemmy.dbzer0.com
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  16 hours ago

                  Every branch you have deploys on commit? You have to fully QA all of your code before it goes into any sort of source control?

                  • neonred@lemmy.world
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    edit-2
                    16 hours ago

                    Not quite.

                    • Every commit is just a local commit
                    • Every push runs pre-hooks which execute bunch of checks, for example linters, style checkers, etc. and prevent a push if something is not perfect
                    • After every push the CI/CD pipeline runs on origin
                    • Every run of the pipeline executes again checks with linters but also securoty checks for CVEs on dependencies and runtime
                    • Every pipeline run also executes all tests such as unit tests, scenario tests, integration tests
                    • If any of the above fails, the pipeline fails and stops
                    • Only if everything is okay, one can deploy on dev, the first stage
                    • Only if this is okay, the artifact gets pushed to the central artifact store
                    • Only if this suceesa a prod deployment can run, which pulls the artifact from the store
                    • Runners for dev and prod are distinct and don’t have rights the other has, the only common contact point is the artifact store

                    That’s an extremely very basic overview with many steps and concepts omitted but you get the idea.

        • 4am@lemmy.zip
          link
          fedilink
          arrow-up
          3
          ·
          21 hours ago

          Take down prod while I’m on call and seeing my kid and I shall return the favor

        • chellomere@lemmy.world
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          edit-2
          20 hours ago

          I agree. I absolutely hate when some pesky git hook rejects some debug code I wrote that I want to commit. Mind you, commit, not integrate. This is the situation where I whip out git commit -n.

    • neonred@lemmy.world
      link
      fedilink
      arrow-up
      2
      arrow-down
      3
      ·
      18 hours ago

      If you have tests you have to automate them and have a pipeline which stops any deployments when these tests fail. You definitely have a mindset issue and not a management or tool issue. I am not sorry but as a DevOps Engineer I can only say you guys are a lousy hack and should probably seek a different job.