<p>I would say that instead of describing a CI/CD system by the products/tools that you use, you should be describing the system by the purpose of each step in the system. Instead of saying "I have a Jenkins server that builds the artifacts, stores them in Artifactory, then Puppet deploys the artifacts to EC2." You could say, "Our build server creates and stores our artifacts in an artifact repository. Then our configuration management software detects the artifacts and deploys them to our cloud infrastructure." Your colleague can then make the connections and find the correct solution that Microsoft provides. </p>

CC BY-SA 3.0
2017-09-18T14:25:21.293Z
2017-09-18T14:25:21.293Z
Preston Martin
<p>After a chat with a colleague who collaborates with quite high-end projects on Microsoft stack (for example, ASP.Net + MS SQL Server). </p>

<p>An interesting outcome was that although I believe that DevOps must be possible in the Microsoft world as well, my knowledge is too little so that I cannot give good examples how he could organize a CI/CD approach. Indeed in our community there are some hints about Team Foundation Server and PSBuildStack (?), but an <a href="https://docs.microsoft.com/de-de/vsts/build-release/overview" rel="nofollow noreferrer">official source</a> does not reveal all that at a glance. The described hosted services make it even less transparent for a newcomer - is that a cloud build environment like CloudBees/BlueMix?</p>

<p>So, my question is now: how could I describe an example of mature toolchain using established DevOps terms which are valid more or less independent from specific environment/tooling - or do we have to admit that this engineering terminology is not there yet?</p>

<p>Something like this:</p>

<ol>
<li>Source code version control system</li>
<li>Build agents</li>
<li>Automation and packaging scheduling system to encapsulate artefact composition logic</li>
<li>A binary repository (different classes of binaries: libraries, distros, container images)</li>
<li>A configuration repository for different environments</li>
<li>Package and configuration distribution system to encapsulate deployment logic</li>
</ol>

<terminology><checklist>
Exemplify CI/CD to a colleague from Microsoft world using product-neutral terms
Ta Mu
# Exemplify CI/CD to a colleague from Microsoft world using product-neutral terms

(Asked by: username_0 on 2017-09-18)

After a chat with a colleague who collaborates with quite high-end projects on Microsoft stack (for example, ASP.Net + MS SQL Server).

An interesting outcome was that although I believe that DevOps must be possible in the Microsoft world as well, my knowledge is too little so that I cannot give good examples how he could organize a CI/CD approach. Indeed in our community there are some hints about Team Foundation Server and PSBuildStack (?), but an [official source](https://docs.microsoft.com/de-de/vsts/build-release/overview) does not reveal all that at a glance. The described hosted services make it even less transparent for a newcomer - is that a cloud build environment like CloudBees/BlueMix?

So, my question is now: how could I describe an example of mature toolchain using established DevOps terms which are valid more or less independent from specific environment/tooling - or do we have to admit that this engineering terminology is not there yet?

Something like this:

1. Source code version control system
2. Build agents
3. Automation and packaging scheduling system to encapsulate artefact composition logic
4. A binary repository (different classes of binaries: libraries, distros, container images)
5. A configuration repository for different environments
6. Package and configuration distribution system to encapsulate deployment logic

**Tags:** terminology, checklist


---

## 1 answers

### Answer by username_1 on 2017-09-18. Score: 3 | Accepted answer

I would say that instead of describing a CI/CD system by the products/tools that you use, you should be describing the system by the purpose of each step in the system. Instead of saying "I have a Jenkins server that builds the artifacts, stores them in Artifactory, then Puppet deploys the artifacts to EC2." You could say, "Our build server creates and stores our artifacts in an artifact repository. Then our configuration management software detects the artifacts and deploys them to our cloud infrastructure." Your colleague can then make the connections and find the correct solution that Microsoft provides.


---

