Post reply

DevOps in Space

  • April 13, 2021 at 12:00 am

    #3865748

    Comments posted to this topic are about the item DevOps in Space

  • April 13, 2021 at 4:13 am

    #3870356

    Interesting and appropriate parallel you bring up... SpaceX has blown up and crashed as many rockets as I've seen DevOps projects fail for similar reasons. 😉

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • April 13, 2021 at 7:55 am

    #3870397

    The whole point of DevOps is that it isn't a project, it isn't a team, it is a way of working and a culture.

    Culture changes are the hardest to implement.  They require active support from above and a willingness from below and above all patience.  There are practices that support a DevOps culture and tools to help support the practices.  I see a few of common mistakes

    • Focusing on the tools first then continue doing things in the wrong order.
    • Trying to change/adopt too much at once and everything is a mess of uncertainty.
    • Forgetting that DevOps is primarily about people and ways of nurturing working together

    I think it is important to have a clear statement of what you want from a DevOps culture.  Reliability? Rapid deployments? Reduction in SPOFs (Single Point of Failures).

    For the various practises that support DevOps I would look at the ones that make me nervous and ask two questions

    • What is it that makes me nervous about this practise?
    • What do I need for me to address that nervousness?

    For example I might be nervous about allowing a wider audience to deploy database changes.  To address that we might do the following.

    • Place the DB under source control
    • Every DB developer has a local instance that is built from source control on which they do their development
    • Have a DB test suite that will pick up a substantial number of mistakes (surprisingly effective this one)
    • Segregate changes based on risk and clear guidance as to whether something is high or low.  Low risk = peer review by 2nd DB developer, High risk = peer review by DBA.
    • Allow deployment up through environments but have gatekeepers (most definitely not a single gatekeeper) from PROD.

    You won't get to CI/CD in a day but at least you know that is the direction of travel.

    One of the earliest things we did was make the metrics the DBAs looked at available to developers on their dashboards.  This was in response to feedback where development teams said "Look, we would love to help you but we simply don't have access to the things you are tearing your hair out over".

    LinkedIn Profile

  • April 13, 2021 at 11:18 am

    #3870460

    Steve, you were 'excited about the prospects if sending others'.  There were a number of folks in my career I would have been excited to send also!

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • April 13, 2021 at 1:05 pm

    #3870506

    Dave, I agree with you. Changing a culture, especially one that actively opposing the change, is difficult. In the state government department I work in, we have no competition. Therefore, I believe the biggest incentive to change is gone. It's just so much easier to always do what they've done for decades. There is support from upper management, but I like the way you put it, the support isn't active. I'm guessing they just don't know how. We occasionally get the message that we're going to adopt DevOps, but with no plan as to how. I know that almost without exception all my peers are adamantly opposed to DevOps. At this point I'm learning the tools, because that's the only thing I can do. I make what changes I can. I introduced the idea of having separate branches in source control. That was surprisingly controversial, but they did realize that it was better than our previous habit of tromping on one another's code upon check-in.

    Oh well, baby steps.

    Rod

  • April 13, 2021 at 3:12 pm

    #3870570

    skeleton567 wrote:

    Steve, you were 'excited about the prospects if sending others'.  There were a number of folks in my career I would have been excited to send also!

    Lol, still think of a few people I'd be happy to have take my spot.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply