1

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:

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, as coordinated by an organisation that uses 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

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

Sources: https://devops.com/devops-2017-cdos-care/

Improve this question
9
  • 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).
    – THelper
    Mar 17, 2017 at 8:01
  • thank you! now it looks much clearer than what I have started with :-)
    – Ta Mu
    Mar 17, 2017 at 9:43
  • 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!
    – Pierre.Vriens ♦
    Mar 17, 2017 at 10:48
  • 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.
    – Ta Mu
    Mar 17, 2017 at 13:36
  • 1
    @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.
    – Richard Slater
    Mar 18, 2017 at 10:41

2 Answers 2

Reset to default
2

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.

Improve this answer
5
  • 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)
    – Tensibai
    Mar 22, 2017 at 8:12
  • @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!
    – Pierre.Vriens ♦
    Mar 22, 2017 at 8:43
  • 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
    – Tensibai
    Mar 22, 2017 at 8:53
  • @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 ... some day.
    – Pierre.Vriens ♦
    Mar 22, 2017 at 9:02
  • I do really think we're getting out of bounds for comments, could be an interesting talk in chat that said.
    – Tensibai
    Mar 22, 2017 at 9:08
2

I don't think the image you mentioned is really in contradiction with the corresponding text. From the 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.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.