Skip to main content
13 events
when toggle format what by license comment
Jan 17, 2018 at 12:38 vote accept Richard Slater
Mar 21, 2017 at 17:07 comment added Tensibai @Pierre.Vriens at the end of the day, you address the concern with the last paragraph about reporting tools. This sounds a valid implementation of even if the number of people are allowed to push in production, the actions are tracked and the audit can't be altered by those persons to hide their actions.
Mar 21, 2017 at 17:05 comment added Pierre.Vriens @Tensibai merci for the kudos, toughest part of it is to avoid it becomes a book (manual). I'd be interested to hear if this helps to address your prior comments such as about those lists with 6/7 persons. Referring to my updated answer, I trust you understand I'd say something like "well, it depends what you're up to, and what you have authorization for, which head you are wearing, etc". Does that makes sense? Also, what's your opinion about yes/no fitting in a DevOps-organization? BTW: what I wrote in my answer is not SF, that's how we use to do it for over 2 decades already ...
Mar 21, 2017 at 17:00 comment added Pierre.Vriens @RichardSlater I just completed my improved version of my answer ...
Mar 21, 2017 at 17:00 comment added Tensibai @Pierre.Vriens Can't upvote twice, great extension :)
Mar 21, 2017 at 16:58 history edited Pierre.Vriens CC BY-SA 3.0
added 4237 characters in body
Mar 21, 2017 at 8:01 comment added Richard Slater Thank you for putting so much time into an answer. I am actually thinking of implementing a 3-person rule, in that, one developer writes the code, a different developer reviews the code and a third person presses the release button to deploy the code. The other consideration is because this is part of a company wide Agile/DevOps adoption the development teams are quite small, with the net effect of small groups of people having production access to thin slice of production, this seems to be favourable from a risk perspective.
Mar 20, 2017 at 21:20 comment added Tensibai :) you know as me bank auditors like the validators list being as restricted as possible, when the list grow there's a hard need for a strict habilitation process around along with a strict following of Human Resources in this list I think :)
Mar 20, 2017 at 21:10 comment added Pierre.Vriens Aha, I smell something about those lists with 6/7 persons that need clarification. I'll try to add a sample to clarify/illustrate the segragation with the typical roles / workflow steps you could configure (tomorrow)
Mar 20, 2017 at 21:00 comment added Tensibai I agree auditors like it absolutely, I just missed how this relate/fit with the ´explosion' of access, which auditor usually doesn't like when the list contains more than 6 to 7 persons. Saying it doesn't fit is an absolutely valid answer IMHO.
Mar 20, 2017 at 20:52 comment added Pierre.Vriens @Tensibai "if" devs would have the auth (role) of (eg) final approval for prod (which they typically do NOT have in such organisations), then such server (started task) would start the deployment. And as per the title of the question, I think this is "a" possible answer. One could question however if this is what we would call a DevOps organization, but I do know that auditors really like this kind of "configurable" segragation of duties (eg: four-eyes and variations of that). Maybe Richard can help us with his viewpoint on this?
Mar 20, 2017 at 20:36 comment added Tensibai That's sounds like a basic implementation of top-down risk assessment, I don't get how it address the question on how this could be implemented in a devops manner where devs would have the rights to trigger the ´deploy' switch. Is the idea that you can't do it in a devops organization?
Mar 20, 2017 at 20:25 history answered Pierre.Vriens CC BY-SA 3.0