• William@lemmy.world
    link
    fedilink
    arrow-up
    22
    ·
    11 months ago

    Even if you release multiple times every day, refusing to release on Friday still makes sense. It’s not about expecting bugs, it’s about guaranteeing that your devs’ time is their own. If you aren’t okay with paying your devs for time they spend dealing with their own problems at home (without charging them their PTO time for it!) then you shouldn’t be okay with making them work on weekends, no matter how rare it is.

    • rglullis@communick.newsOP
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      6
      ·
      11 months ago

      The author ended up creating a strawman. Allen’s argument was pretty clear: if your deltas are small and your deploy system is fully automated, then no one should be afraid of the risk of deploying.

      Given that, if I deploy on a Monday morning and there is a bug on the new release, you revert, reproduce the issue in staging and push only new code when it is fixed. Same thing if I were deploying on a Thursday afternoon or a Friday at 7PM.

      • MajorHavoc@lemmy.world
        link
        fedilink
        arrow-up
        9
        ·
        11 months ago

        Only inexperienced developers* are unafraid of deploying right before leaving the office.

        There’s an entire untapped universe of possible new ways that things can go horribly wrong.

        *Experienced developers who hate their boss and their colleagues, too, technically.

              • MajorHavoc@lemmy.world
                link
                fedilink
                arrow-up
                4
                ·
                11 months ago

                It’s not about how hard the problem is to reverse, it’s about respecting the team enough not to call them on Saturday.

                • rglullis@communick.newsOP
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  arrow-down
                  4
                  ·
                  edit-2
                  11 months ago

                  Again: if the changes are small enough and you have automated checks in place, they should not require manual intervention.

                  Plus, what happens if a deploy on Thursday has a bug which only is manifested on a Saturday?

                  • MajorHavoc@lemmy.world
                    link
                    fedilink
                    arrow-up
                    7
                    ·
                    11 months ago

                    Again: if the changes are small enough and you have automated checks in place, they should not require manual intervention.

                    You’ve used the magic word “should”. “Should is famous last words.” The trick to keeping developer talent is not to risk the developer’s weekend plans on “should”.

                    And yes, maybe I’m only risking our cloud ops person’s weekend plans. Same principle applies.

                    Every change that isn’t already an active disaster recovery can wait for Monday.

                  • MajorHavoc@lemmy.world
                    link
                    fedilink
                    arrow-up
                    5
                    ·
                    11 months ago

                    Good question.

                    Since we’re doing a deep dive, I’ll share some additonal context. I’m the manager of the developers. On my team, that means the call comes to me first.

                    I have had Thursday deploys that resulted in bugs discovered on Saturday. Here’s how the conversation on Saturday went:

                    “Thanks for letting me know. So we didn’t notice this on Friday?”

                    “No, it’s subtle.” Or “We noticed, but didn’t get around to letting you know until now.”

                    “Okay. I’ll let the team know to plan to rollback at 0900 on Monday, then we will start fixing any damage that happened on Friday, and the weekend.”