1

I know for example following DevOps relevant concepts related to time:

  • MTTR - mean time to recovery
  • Sprint length - fixed agreed time to hand over features to customer (what this specificall implies is part of DoD I think)

Now my question - how do you name the lead time from a code commit hitting the repository to a first running deployment where you could do a first acceptance test to the feature? To a production system?

  • Why do you skip test, i.e. dtap in your question? – 030 Feb 22 '18 at 16:03
  • Tests are not meant to be skipped. I'm after tge pipeline lead time frame term. What's dtap? – Peter Feb 22 '18 at 18:47
1

From code repository to any environment, as a running software would be "Time to Deploy" ( which is different from deployment time, btw ).

From code repository all the way to production environment, the best aproximation is time to market (TTM), taking aside that time to market does involve the conceptual design of a product.

But as you said you are tagging an pipeline, I should advise:

Use the tags that makes sense: to you, your team and to your product.

A common pipeline could be : BUILD > TEST > DEPLOY

But we could tag the same pipeline, making more steps visible, ie : SOURCE CHECKOUT > CODE CHECK > UNITARY TESTS > BUILD > INTEGRATED TESTS > DEPLOY > ACCEPTANCE TESTS

As a rule, if you have trouble on one step and must check the output to understand whats going on, this step could be divided in one or more tags.

If makes sense to you, you could even tag something like SOURCE CHECKOUT IDLE TIME ( the time took for the build machine to connect to the repository server, before downloading the source )

Hope this could be useful, happy tagging!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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