Software Maturity with Release Management

  • Comments posted to this topic are about the item Software Maturity with Release Management

  • If the deployment script is written poorly it could run perfectly in test environments and still mess up in production. Some scripts are written to fix data. But data in production changes. So the script has to account for that possibility, to be able to succeed even if the data changes.

  • If it fails in production, it wasn't written well, nor was it tested well. You should have a few cases in your test environment, with curated data designed to look like the possibilities in production. Using some random data or a few rows developers created, or even old restores, aren't sufficient.

    Nothing will be perfect, but having the script run automatically reduces the changes of human error. It doesn't mean that your scripts won't make a mistake, but that at least you don't have script mistakes, plus human execution mistakes. Why wouldn't you want to remove that from the list of potential issues?

    Would you then need to fix things? Perhaps, but how is that different from you running the script yourself and finding errors?

  • I don't know, Steve. I agree with you in principle. But I notice, at least in my current position, that there is a very high tolerance for pain in how software is deployed. There's a lot of ad hoc, fly by the seat of your pants deployment. Now this isn't across the board type of thing, but it is much more prevalent than I would have thought, for such a large organization. I've no idea why its tolerated, but it is.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod,

    I think many companies tolerate pain in deploying software. I have no idea why myself, but I'm more baffled as to why Developers and Operational staff don't do better.

  • Devs, infrastructure guys and DBAs have to work together to get this working and thus prove the value of DevOps.

    Like all things if you adopt the disciplines and put in the work you reap the rewards

  • Steve Jones - SSC Editor (5/16/2016)


    Rod,

    I think many companies tolerate pain in deploying software. I have no idea why myself, but I'm more baffled as to why Developers and Operational staff don't do better.

    Because many companies would rather have it now than have it right. It's difficult to resist that pressure.

  • Marcia J (5/18/2016)


    Steve Jones - SSC Editor (5/16/2016)


    Rod,

    I think many companies tolerate pain in deploying software. I have no idea why myself, but I'm more baffled as to why Developers and Operational staff don't do better.

    Because many companies would rather have it now than have it right. It's difficult to resist that pressure.

    I think there's a lot of truth to that, Marcia.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Indeed

  • Currently we have a few hundred customers running standalone systems - current estimates are that the cloud solution is still a year away. The once slick install/update process has needed increasing manual intervention over the past year to the point where an update took up to two+ hours. A day working on the scripts has now reduced this to around five minutes (and is saving a fortune). The only area that still needs slickification is the addition of new tables and new, or modified, fields. I doubt I will ever get my wish of a clear set of requirements so that the database design could be stable for a few months! :hehe:

  • Who wants stability? That's why they pay you the big bucks, right? 😉

  • Steve Jones - SSC Editor (5/16/2016)


    ...Would you then need to fix things? Perhaps, but how is that different from you running the script yourself and finding errors?

    The difference is that an automated script documents the error made whereas a manual script may or may not.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Steve Jones - SSC Editor (5/16/2016)


    Rod,

    I think many companies tolerate pain in deploying software. I have no idea why myself, but I'm more baffled as to why Developers and Operational staff don't do better.

    I think it is in part due to scripts needing to refer to machines that differ in name/address in production and security credentials are difficult to parameterise in an automated fashion. It's just a little too hard for some peoples' level of enthusiasm for automation.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 13 posts - 1 through 12 (of 12 total)

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