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/

Community
  • 1
Ta Mu
  • 6,792
  • 5
  • 43
  • 83

2 Answers2

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.

Dan Cornilescu
  • 6,780
  • 2
  • 21
  • 45
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.

Pierre.Vriens
  • 7,225
  • 14
  • 39
  • 84