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

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

<p>But as you said you are tagging an pipeline, I should advise:</p>

<p><strong>Use the tags that makes sense: to you, your team and to your product.</strong> </p>

<p>A common pipeline could be : BUILD > TEST > DEPLOY </p>

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

<p>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.</p>

<p>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 )</p>

<p>Hope this could be useful, happy tagging!</p>

CC BY-SA 3.0
2018-02-23T20:11:41.447Z
2018-02-23T20:11:41.447Z
Rodrigo Medeiros
<p>I know for example following DevOps relevant concepts related to time:</p>

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

<p>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?</p>

CC BY-SA 3.0
2018-02-22T16:03:51.557Z
Why do you skip test, i.e. dtap in your question?
030
CC BY-SA 3.0
2018-02-22T18:47:24.950Z
Tests are not meant to be skipped. I'm after tge pipeline lead time frame term. What's dtap?
Ta Mu
<terminology><continuous-delivery><metrics><speed>
What is the proper term for lead time from commit to deployment?
Ta Mu
# What is the proper term for lead time from commit to deployment?

(Asked by: username_0 on 2018-02-22)

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?

**Tags:** terminology, continuous-delivery, metrics, speed

> **Comments:**
> **username_1**: Why do you skip test, i.e. dtap in your question?  
> **username_0**: Tests are not meant to be skipped. I'm after tge pipeline lead time frame term. What's dtap?  

---

## 1 answers

### Answer by username_2 on 2018-02-23. Score: 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!


---

