June 25, 2016 at 12:18 pm
Comments posted to this topic are about the item DevOps and Security
June 25, 2016 at 1:08 pm
Personally, I think that any system that allows Developers to promote to prod or allows for unchecked code to be promoted automatically is just asking for trouble no matter what buzzword may be associated with it.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 25, 2016 at 7:48 pm
I understand concerns, but remember, Jeff, no code is ever unchecked. Part of the process is ensuring that code runs through a set of checks, whatever those are. Those can include code reviews, manual QA, and more. This can also be the creation and review of scripts by the DBA.
The promotion is set to move in an automated fashion, the same to every environment. This takes humans out of the making silly mistakes in deployment.
June 27, 2016 at 2:16 am
Jeff Moden (6/25/2016)
Personally, I think that any system that allows Developers to promote to prod or allows for unchecked code to be promoted automatically is just asking for trouble no matter what buzzword may be associated with it.
As a smaller company that has always been our way of working. We just can't (or haven't been able to) afford a team to solely organise release. Just because we are able to promote to prod doesn't mean we do it randomly or carelessly, at the end of the day it's us sorting out the issues.
We are trying to move to a more formal staged model as success has brought us a larger team, but there are plenty of valid ways of working - assuming you are not working on stuff where anyone dies!
June 27, 2016 at 2:59 am
I find that automating much of a release stops "tinkering" i.e. people who think they know better making changes out of process (both automated and manual). For me, this is the most dangerous of practices as those who think they know better than to comply with the processes are often those that the processes are protecting us from.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 27, 2016 at 6:20 am
Steve Jones - SSC Editor (6/25/2016)
I understand concerns, but remember, Jeff, no code is ever unchecked. Part of the process is ensuring that code runs through a set of checks, whatever those are. Those can include code reviews, manual QA, and more. This can also be the creation and review of scripts by the DBA.The promotion is set to move in an automated fashion, the same to every environment. This takes humans out of the making silly mistakes in deployment.
The following comment from the article appears to say otherwise on all cases cited above.
From the Article
Or, at least, allow us to determine who made the change and when the issue appeared.
I can see the huge utility in automated pre-reviews before going to a code review. I can even see the automated promotion of some managed code. But, when it comes to the modification of database objects, no one has ever run into the problem of, say, having some statistics on a column that needs to be dropped stop the drop because the prod system decided it needed to create the statistics but the Dev/QA system did not.
Our deployments to prod are "automated" in that they are scripted but it's not always possible for a program to decide what should be committed when and it's certainly not possible to do it all in a single transaction when there are certain inter and intra object dependencies. Even the wonderfully useful Red-Gate compare frequently fails to rise to such occasions.
To be sure, automation of code promotion breeds a bit of laziness and I seriously doubt that no one would abuse it to promote unreviewed or even untested code. If someone decides to automate such things, they really need to establish some safe guards that I don't see a lot of people establishing.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2016 at 1:59 am
Jeff Moden (6/27/2016)
...To be sure, automation of code promotion breeds a bit of laziness and I seriously doubt that no one would abuse it to promote unreviewed or even untested code. If someone decides to automate such things, they really need to establish some safe guards that I don't see a lot of people establishing.
Absolutely agree. Reviews need to form part of the automation process i.e. no code released until the peer review completion is digitally captured. I have seen this done at a number of places.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 30, 2016 at 3:37 am
I work in DevOps, and we don't let developers promote to Production. They take the build all the way through their pipeline, then hand it over to Production Support (a team of DBAs and DevOps Engineers), who deploy it to a pre-Production environment that is identical to Production. If it succeeds in pre-Prod, that build is promoted to Production. If it fails, we take the next successful build to come out of the pipeline and put that into pre_Production, and so on.
As well as being safer, it frees developers up to do what they do best, and they don't spend half their time providing Production support.
July 13, 2016 at 3:07 am
Beatrix Kiddo (6/30/2016)
I work in DevOps, and we don't let developers promote to Production. They take the build all the way through their pipeline, then hand it over to Production Support (a team of DBAs and DevOps Engineers), who deploy it to a pre-Production environment that is identical to Production. If it succeeds in pre-Prod, that build is promoted to Production. If it fails, we take the next successful build to come out of the pipeline and put that into pre_Production, and so on.As well as being safer, it frees developers up to do what they do best, and they don't spend half their time providing Production support.
I agree with checks on the promote-to-production path. However, I can't stand developers who have no support experience, and found over the years that getting the developers involved in support (whether that's production support or customer support depends of course on what sort of company it is) fairly quickly improves code quality, because they see what inadequate checking can do and to want their code to do things like that.
And although it's important to have checks, it's equally important to ensure that those checks don't cause bottlenecks. Building artificial barriers between development and release, between production and support, or between development and operations tends to create bottlenecks, which tends to make people try to meet deadlines by bypassing those bottlenecks, which means checks are bypassed so output quality goes down and customers (the end users) get a worse experience.
Of course "devops" became n in buzz-word and all sorts on exagerrated nonsense now calls itself devops. I found devops much easier fourty five years ago when it was just the way things were done in a high-grade shop and it didn't have that fancy name or suffer a load of hype about the fancy name from journalists peddling tripe.
Tom
August 2, 2016 at 5:00 pm
TomThomson (7/13/2016)
...I can't stand developers who have no support experience...
Totally agree. As a developer I value the experience of supporting production. It ensures understanding and a sense of responsibility.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply