Answers: <p>Your question doesn't seem to make any assumption about the platform/OS it is about. Which is why it may make sense to add an answer about how part of such toolchain looks like in a mainframe environment. My answer is based on using the SCM product where I'm most familiar with (not sure if it's needed to disclose the product name).</p>
  
  <p>Your example about "<em>Plan, Code, Build, Test, Release, Deploy, Operate, Monitor</em>" seems to be missing these crucial phases:</p>
  
  <ol>
  <li><p>Enforce predictable problems in production to be addressed before they actually have an impact in production (sounds like sales talk, no?). You might think this is just "impact analysis", but that is not it:</p>
  
  <ul>
  <li><strong>Impact analysis</strong> is what you do in the plan-phase (we all know that, right?).</li>
  <li><strong>Audit</strong> (= name of the phase we use for it), is around the time that the developer thinks/claims to be ready. Something like "unless there is anything else that may have happened in production while I was working on my change, I'm done and recommend to move forward". Think of things like "version regression issues". Eg because last night a fix was applied to production and you didn't retrofit that fix, so if you move forward with your change, you'll wipe out the fix again ... bad luck if you do!</li>
  </ul></li>
  <li><p>Give me a red button, so that if anything else fails (and production is impacted), I just have to push a magic button, be patient (for a few secs) and be 100% sure a rollback completed with 0 rebuilds of any kind (= <strong>Backout</strong> is the name of the phase we use for it).</p>
  
  <p>This boils down to "component level backups" of any files/components you will be updating by your change in production, whereas these backups are made at the very moment the change is going to be applied. and this for any type of artifacts included in the change.</p>
  
  <p>If later on (5 mins, 2 days or 1 week later) something goes wrong in production, and it turns out to be caused by your change, all you have to do is to have an automated procedure (the red button!) in place that you can launch, and which simply restores the backup you should have available.</p>
  
  <p>Attention, if there were database updates involved, this backout may not be an option anymore. While things like "backups overlaid" (because of concurrent changes/fixes got applied to production) is another scenario where the red button is no longer available.</p></li>
  </ol>
  
  <p><strong>Easy, no</strong>? </p>
  
  <p>PS: I leave it to everybody's own judgement if my answer is yes or no DevOps-compliant.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-22T08:12:01.240Z
Answers: I'd argue the audit you're describing here is within the Test phase. The rollback possibility is one way, usually in a cyclic SDLC you would push a new release to fix the defects instead of rolling back, in other words: always go forward. (This is just an informative comment, nothing to change in the answer IMHO)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-22T08:43:20.480Z
Answers: @Tensibai "test" IMO i about something you're trying to use/execute, while audit is about verifying/comparing things (and even though 'verify' is in the image in the question, it is not in any of the 3 examples). About fix the defects instead of rollback (backout): I agree a fix is indeed recommended. But if you have the means to do a backout, you also buy time to create a high quality (tested, reviewed, etc) fix. And if 1 sec production down costs 1,000.000 eur (or usd) and you need 30 secs for backout versus 5 mins for a fix, which one do you think a CEO would prefer? I bet: the red button!
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-22T08:53:16.373Z
Answers: Test could be functionnal test to ensure the system still compute the same fee for a specific contract for example. And yes, if your app dB schema is compatible for version N and N+1, deploying the version N back instead of waiting th fix is a good option
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-22T09:02:56.423Z
Answers: @Tensibai That kind of testing is indeed valid (does apply), but I can think of a number of situations (things in your change that put production at risk) that you might not be able to find by testing. If I make you curious enough, how about using [this link](http://devops.stackexchange.com/questions/ask) ... some day.
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-22T09:08:38.937Z
Answers: I do really think we're getting out of bounds for comments, could be an interesting talk in chat that said.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-21T20:58:01.947Z
Answers: 2017-03-21T20:58:01.947Z
Answers: Pierre.Vriens
Answers: <p>I don't think the image you mentioned is really in contradiction with the corresponding text. From the <a href="https://en.wikipedia.org/wiki/DevOps_toolchain#Preprod" rel="nofollow noreferrer">Preprod</a> section further down on the same page (emphasis mine):</p>
  
  <blockquote>
    <p><strong>Preprod</strong></p>
    
    <p>Preproduction or "preprod" refers the activities involved once the
    release is ready for deployment, often also referred to as staging or
    <strong>packaging</strong>.</p>
  </blockquote>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-21T18:51:29.120Z
Answers: 2017-03-21T18:51:29.120Z
Answers: Dan Cornilescu
Body: <p>It seems that many people somehow try to define the software development process using a DevOps tools model but there is no alignment; still I assume that this is more a question of maturity/alignment, not of matter of taste.</p>
  <p><strong>Question</strong>: What are further known DevOps operation models?</p>
  <p>Some examples I've seen at available popular sources:</p>
  <ul>
  <li><p>Plan, Develop, Test, Release, Operate</p>
  </li>
  <li><p>Plan, Code, Build, Test, Release, Deploy, Operate, Monitor</p>
  </li>
  <li><p>Requirements, Development, Build, Testing, Deployment, Execution</p>
  </li>
  </ul>
  <p>Here is a quote from the Wikipedia page for the <a href="https://en.wikipedia.org/wiki/DevOps_toolchain" rel="nofollow noreferrer">DevOps toolchain</a>:</p>
  <blockquote>
  <p>A <strong>DevOps toolchain</strong> is a set or combination of tools that aid in the delivery, development, and management of applications throughout the <a href="https://en.wikipedia.org/wiki/Software_development_lifecycle" rel="nofollow noreferrer">software development lifecycle</a>, as coordinated by an organisation that uses <a href="https://en.wikipedia.org/wiki/DevOps" rel="nofollow noreferrer">DevOps</a> practices.</p>
  <p>Generally, DevOps tools fit into one or more activities, which supports specific DevOps initiatives: Plan, Create, Verify, Preprod, Release, Configure, and Monitor.</p>
  <p>Another proposed toolchain model was referenced in 2014 as coming from &quot;an unknown source&quot; as Plan, Code, Build, Test, Release, Deploy, Operate and Monitor.</p>
  </blockquote>
  <p>However, that same Wikipedia page also contains an image which looks like so:</p>
  <p><a href="https://i.sstatic.net/7NmOQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/7NmOQ.png" alt="Devops Toolchain stages on Wikipedia" /></a></p>
  <p>This image, IMO, does not correlate with the text on that page.</p>
  <p><em>DevOps Toolchain stages on Wikipedia, <a href="https://commons.wikimedia.org/w/index.php?curid=51215412" rel="nofollow noreferrer">By Kharnagy - Own work, CC BY-SA 4.0Wikipedia</a></em></p>
  <p>Sources:
  <a href="https://devops.com/devops-2017-cdos-care/" rel="nofollow noreferrer">https://devops.com/devops-2017-cdos-care/</a></p>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-17T08:01:41.540Z
Comments: I think I understand a bit more what it is you are asking, so I've made some modifications to your question to clarify things. It's pending approval from you or 3 other users. I you disagree with my changes, feel free to not accept my edit (or do a rollback if other people approved it).
Comments: THelper
Comments: CC BY-SA 3.0
Comments: 2017-03-17T09:43:10.087Z
Comments: thank you! now it looks much clearer than what I have started with :-)
Comments: Ta Mu
Comments: CC BY-SA 3.0
Comments: 2017-03-17T10:48:25.013Z
Comments: With the help from @THelper, "I" (think I) now also start to better understand what this question was all about. So to "Mr or Ms J" (just to keep the mystery ... hoping this user will ever get changed to some more trustworthy username ... eg to match with the one from LinkedIn ...): please review my changes I applied to your question. If you don't like it at all, just perform a rollback. Could well be that I introduced some mistake also, if so then please further adapt. Good luck!
Comments: Pierre.Vriens
Comments: CC BY-SA 3.0
Comments: 2017-03-17T13:36:30.857Z
Comments: dear Pierre, once accepting the changes I cannot see further edit suggestions by my low status I consider. Sure your contribution is excellent but how can I active it? p.s. reopened and saved again. See that you've added Wikipedia quote, "IMO" to the last sentence etc.
Comments: Ta Mu
Comments: CC BY-SA 3.0
Comments: 2017-03-17T16:20:25.780Z
Comments: Hi Mr./Ms. J, welcome to the real world of SE ... where users can earn "privileges". For more about that, have a look at [the help pages](http://devops.stackexchange.com/help) (your profile shows you do not have the "informed" badge yet ...). Believe it or not, but "I" already have the privilege to change your question, without your ***approval***. However, I often (always) leave a comment like my previous one about rollback, etc (not all users like such attempts to help). Get it? PS about "Mr./Ms.": Up to you to disclose which one is right (I know which one it is ...)
Comments: Pierre.Vriens
Comments: CC BY-SA 3.0
Comments: 2017-03-17T22:05:18.747Z
Comments: I still think there is no answer, it's opinion based, or at least highly dependent on the company/team whishes and way of work. Covering the whole picture to answer would not fit IMHO. Hence my vote to close but removed the downvote, it's  better defined question now
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-18T10:41:59.373Z
Comments: @Tensibai I concur, there is no "one true answer" to this question there never will be - it's opinion based.  The most I can draw out of this question is along the lines of "What do you call the combination of people, process and tools in a DevOps organisation" - to which I would be able to answer a "DevOps Operating Model" or "Target Operating Model" as part of a wider "Business Plan" that includes a move to a DevOps way of working.
Comments: Richard Slater
Comments: CC BY-SA 3.0
Comments: 2017-03-21T09:16:24.213Z
Comments: @Richard Slater - thanks for this input - maybe it's better to rename the question to "what are further known DevOps operating models"?
Comments: Ta Mu
Comments: CC BY-SA 3.0
Comments: 2017-03-21T17:58:30.170Z
Comments: @J.Doe I think that would be a valuable question.
Comments: Richard Slater
Tags: <terminology><culture><toolchain>
Title: What are further known DevOps operation models?
UserDisplayName: Ta Mu
ThreadText: # What are further known DevOps operation models?
  
  (Asked by: username_0 on 2017-03-15)
  
  It seems that many people somehow try to define the software development process using a DevOps tools model but there is no alignment; still I assume that this is more a question of maturity/alignment, not of matter of taste.
  
  **Question**: What are further known DevOps operation models?
  
  Some examples I've seen at available popular sources:
  
  * Plan, Develop, Test, Release, Operate
  * Plan, Code, Build, Test, Release, Deploy, Operate, Monitor
  * Requirements, Development, Build, Testing, Deployment, Execution
  
  Here is a quote from the Wikipedia page for the [DevOps toolchain](https://en.wikipedia.org/wiki/DevOps_toolchain):
  
  > A **DevOps toolchain** is a set or combination of tools that aid in the delivery, development, and management of applications throughout the [software development lifecycle](https://en.wikipedia.org/wiki/Software_development_lifecycle), as coordinated by an organisation that uses [DevOps](https://en.wikipedia.org/wiki/DevOps) practices.
  >
  > Generally, DevOps tools fit into one or more activities, which supports specific DevOps initiatives: Plan, Create, Verify, Preprod, Release, Configure, and Monitor.
  >
  > Another proposed toolchain model was referenced in 2014 as coming from "an unknown source" as Plan, Code, Build, Test, Release, Deploy, Operate and Monitor.
  
  However, that same Wikipedia page also contains an image which looks like so:
  
  [![Devops Toolchain stages on Wikipedia](https://i.sstatic.net/7NmOQ.png)](https://i.sstatic.net/7NmOQ.png)
  
  This image, IMO, does not correlate with the text on that page.
  
  *DevOps Toolchain stages on Wikipedia, [By Kharnagy - Own work, CC BY-SA 4.0Wikipedia](https://commons.wikimedia.org/w/index.php?curid=51215412)*
  
  Sources:
  <https://devops.com/devops-2017-cdos-care/>
  
  **Tags:** terminology, culture, toolchain
  
  > **Comments:**
  > **username_1**: I think I understand a bit more what it is you are asking, so I've made some modifications to your question to clarify things. It's pending approval from you or 3 other users. I you disagree with my changes, feel free to not accept my edit (or do a rollback if other people approved it).  
  > **username_0**: thank you! now it looks much clearer than what I have started with :-)  
  > **username_2**: With the help from @username_1, "I" (think I) now also start to better understand what this question was all about. So to "Mr or Ms J" (just to keep the mystery ... hoping this user will ever get changed to some more trustworthy username ... eg to match with the one from LinkedIn ...): please review my changes I applied to your question. If you don't like it at all, just perform a rollback. Could well be that I introduced some mistake also, if so then please further adapt. Good luck!  
  > **username_0**: dear Pierre, once accepting the changes I cannot see further edit suggestions by my low status I consider. Sure your contribution is excellent but how can I active it? p.s. reopened and saved again. See that you've added Wikipedia quote, "IMO" to the last sentence etc.  
  > **username_2**: Hi Mr./Ms. J, welcome to the real world of SE ... where users can earn "privileges". For more about that, have a look at [the help pages](http://devops.stackexchange.com/help) (your profile shows you do not have the "informed" badge yet ...). Believe it or not, but "I" already have the privilege to change your question, without your ***approval***. However, I often (always) leave a comment like my previous one about rollback, etc (not all users like such attempts to help). Get it? PS about "Mr./Ms.": Up to you to disclose which one is right (I know which one it is ...)  
  > **username_3**: I still think there is no answer, it's opinion based, or at least highly dependent on the company/team whishes and way of work. Covering the whole picture to answer would not fit IMHO. Hence my vote to close but removed the downvote, it's  better defined question now  
  > **username_4**: @username_3 I concur, there is no "one true answer" to this question there never will be - it's opinion based.  The most I can draw out of this question is along the lines of "What do you call the combination of people, process and tools in a DevOps organisation" - to which I would be able to answer a "DevOps Operating Model" or "Target Operating Model" as part of a wider "Business Plan" that includes a move to a DevOps way of working.  
  > **username_0**: @username_4 - thanks for this input - maybe it's better to rename the question to "what are further known DevOps operating models"?  
  > **username_4**: @J.Doe I think that would be a valuable question.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-03-21. Score: 2 | Accepted answer
  
  Your question doesn't seem to make any assumption about the platform/OS it is about. Which is why it may make sense to add an answer about how part of such toolchain looks like in a mainframe environment. My answer is based on using the SCM product where I'm most familiar with (not sure if it's needed to disclose the product name).
  
  Your example about "*Plan, Code, Build, Test, Release, Deploy, Operate, Monitor*" seems to be missing these crucial phases:
  
  1. Enforce predictable problems in production to be addressed before they actually have an impact in production (sounds like sales talk, no?). You might think this is just "impact analysis", but that is not it:
  
     * **Impact analysis** is what you do in the plan-phase (we all know that, right?).
     * **Audit** (= name of the phase we use for it), is around the time that the developer thinks/claims to be ready. Something like "unless there is anything else that may have happened in production while I was working on my change, I'm done and recommend to move forward". Think of things like "version regression issues". Eg because last night a fix was applied to production and you didn't retrofit that fix, so if you move forward with your change, you'll wipe out the fix again ... bad luck if you do!
  2. Give me a red button, so that if anything else fails (and production is impacted), I just have to push a magic button, be patient (for a few secs) and be 100% sure a rollback completed with 0 rebuilds of any kind (= **Backout** is the name of the phase we use for it).
  
     This boils down to "component level backups" of any files/components you will be updating by your change in production, whereas these backups are made at the very moment the change is going to be applied. and this for any type of artifacts included in the change.
  
     If later on (5 mins, 2 days or 1 week later) something goes wrong in production, and it turns out to be caused by your change, all you have to do is to have an automated procedure (the red button!) in place that you can launch, and which simply restores the backup you should have available.
  
     Attention, if there were database updates involved, this backout may not be an option anymore. While things like "backups overlaid" (because of concurrent changes/fixes got applied to production) is another scenario where the red button is no longer available.
  
  **Easy, no**?
  
  PS: I leave it to everybody's own judgement if my answer is yes or no DevOps-compliant.
  
  > **Comments:**
  > **username_3**: I'd argue the audit you're describing here is within the Test phase. The rollback possibility is one way, usually in a cyclic SDLC you would push a new release to fix the defects instead of rolling back, in other words: always go forward. (This is just an informative comment, nothing to change in the answer IMHO)  
  > **username_2**: @username_3 "test" IMO i about something you're trying to use/execute, while audit is about verifying/comparing things (and even though 'verify' is in the image in the question, it is not in any of the 3 examples). About fix the defects instead of rollback (backout): I agree a fix is indeed recommended. But if you have the means to do a backout, you also buy time to create a high quality (tested, reviewed, etc) fix. And if 1 sec production down costs 1,000.000 eur (or usd) and you need 30 secs for backout versus 5 mins for a fix, which one do you think a CEO would prefer? I bet: the red button!  
  > **username_3**: Test could be functionnal test to ensure the system still compute the same fee for a specific contract for example. And yes, if your app dB schema is compatible for version N and N+1, deploying the version N back instead of waiting th fix is a good option  
  > **username_2**: @username_3 That kind of testing is indeed valid (does apply), but I can think of a number of situations (things in your change that put production at risk) that you might not be able to find by testing. If I make you curious enough, how about using [this link](http://devops.stackexchange.com/questions/ask) ... some day.  
  > **username_3**: I do really think we're getting out of bounds for comments, could be an interesting talk in chat that said.  
  
  ---
  
  ### Answer by username_5 on 2017-03-21. Score: 2
  
  I don't think the image you mentioned is really in contradiction with the corresponding text. From the [Preprod](https://en.wikipedia.org/wiki/DevOps_toolchain#Preprod) section further down on the same page (emphasis mine):
  
  > **Preprod**
  >
  > Preproduction or "preprod" refers the activities involved once the
  > release is ready for deployment, often also referred to as staging or
  > **packaging**.
  
  
  ---
  
  