Skip to content

Commit c92575d

Browse files
mcaspersonmcasperson
committed
line edits
1 parent f810745 commit c92575d

File tree

1 file changed

+42
-40
lines changed

1 file changed

+42
-40
lines changed

‎_includes/pe_vs_devops.html‎

Lines changed: 42 additions & 40 deletions
Original file line numberDiff line numberDiff line change
@@ -56,9 +56,9 @@ <h2>What is DevOps Not?</h2>
5656
<p><i>
5757
The suggestion proposed by the engineering leadership at the time was that everyone should stop what they were doing
5858
and fix the
59-
tests. This is typically sound advice, and very much in line with practices like Test Driven Design (TDD).
59+
tests. This is typically sound advice and very much in line with practices like Test Driven Design (TDD).
6060
Unfortunately, every developer
61-
on the team intrincially understood that fixing the tests was a dedicated project it its own right. There were no
61+
on the team intrinsically understood that fixing the tests was a dedicated project it its own right. There were no
6262
quick wins.
6363
</i></p>
6464

@@ -109,44 +109,46 @@ <h2>What is Platform Engineering?</h2>
109109
implemented platform engineering. This one-to-many relationship between an IDP and the processes used by DevOps
110110
teams demonstrates that architectural decisions are centrally defined and can be implemented on demand.</p>
111111

112-
<p>Consider a world where we had no notion of a CI server. DevOps teams still have the requirement to build and test their
113-
code, which would likely lead to situations where every developer build their code locally, nominated a
114-
"builder" with the authority to produce golden artifacts, or maybe go a step further and implement a rudimentary
115-
centralized solution with cron jobs.
116-
</p>
117-
118-
<p>Now imagine adding a second DevOps team. They too need a solution for building their code. There are 4 ways
119-
common requirements like this will be addressed:
120-
</p>
121-
122-
<ul>
123-
<li>It won't be addressed at all</li>
124-
<li>It will be addressed with a novel solution</li>
125-
<li>It will be addressed with a coincidentally similar solution or a solution recreated from memory</li>
126-
<li>It will be addressed with a common solution</li>
127-
</ul>
128-
129-
<p>It is easy to see that common solutions to common requirements is the only sustainable path for growing
130-
DevOps teams.
131-
</p>
132-
133-
<p>In our hypothetical scenario, the obvious solution is to deploy a CI server. But CI servers had to start somewhere. Jenkins,
134-
one of the most popular open source CI servers, was initially built by Kohsuke Kawaguchi:
135-
</p>
136-
137-
<p class="quote"> Kohsuke was a developer at Sun and got tired of incurring the wrath of his team every time
138-
his code broke the build. He created Jenkins as a way to perform continuous integration – that is, to test
139-
his code before he did an actual commit to the repository, to be sure all was well. Once his teammates saw
140-
what he was doing, they all wanted to use Jenkins.</p>
141-
142-
<p>Thus a common solution to a common requirement was born. It is also no coincidence that Jenkins was born to improve
143-
Kohsuke's DevEx.</p>
144-
145-
<p>While CI servers are a solved problem (at least from the point
146-
of view of an average DevOps team), environments with multiple DevOps teams working side by side will no doubt
147-
have many more common requirements. Addressing these common requirements with artifacts generated by your IDP
148-
is the goal of a platform team.
149-
</p>
112+
<p>Consider a world where we had no notion of a CI server. DevOps teams still have the requirement to build and test
113+
their
114+
code, which would likely lead to situations where every developer build their code locally, nominated a
115+
"builder" with the authority to produce golden artifacts, or maybe go a step further and implement a rudimentary
116+
centralized solution with cron jobs.
117+
</p>
118+
119+
<p>Now imagine adding a second DevOps team. They too need a solution for building their code. There are 4 ways
120+
common requirements like this will be addressed:
121+
</p>
122+
123+
<ul>
124+
<li>It won't be addressed at all</li>
125+
<li>It will be addressed with a novel solution</li>
126+
<li>It will be addressed with a coincidentally similar solution or a solution recreated from memory</li>
127+
<li>It will be addressed with a common solution</li>
128+
</ul>
129+
130+
<p>It is easy to see that common solutions to common requirements is the only sustainable path for growing
131+
DevOps teams.
132+
</p>
133+
134+
<p>In our hypothetical scenario, the obvious solution is to deploy a CI server. But CI servers had to start somewhere.
135+
Jenkins,
136+
one of the most popular open source CI servers, was initially built by Kohsuke Kawaguchi:
137+
</p>
138+
139+
<p class="quote"> Kohsuke was a developer at Sun and got tired of incurring the wrath of his team every time
140+
his code broke the build. He created Jenkins as a way to perform continuous integration – that is, to test
141+
his code before he did an actual commit to the repository, to be sure all was well. Once his teammates saw
142+
what he was doing, they all wanted to use Jenkins.</p>
143+
144+
<p>Thus a common solution to a common requirement was born. It is also no coincidence that Jenkins was born to improve
145+
Kohsuke's DevEx.</p>
146+
147+
<p>While CI servers are a solved problem (at least from the point
148+
of view of an average DevOps team), environments with multiple DevOps teams working side by side will no doubt
149+
have many more common requirements. Addressing these common requirements with artifacts generated by your IDP
150+
is the goal of a platform team.
151+
</p>
150152
<p>
151153
Common artifacts generated by an IDP include:
152154
</p>

0 commit comments

Comments
 (0)