diff options
Diffstat (limited to 'posts/2012-12-16-about-devops.org')
| -rw-r--r-- | posts/2012-12-16-about-devops.org | 41 |
1 files changed, 0 insertions, 41 deletions
diff --git a/posts/2012-12-16-about-devops.org b/posts/2012-12-16-about-devops.org deleted file mode 100644 index d02674c..0000000 --- a/posts/2012-12-16-about-devops.org +++ /dev/null @@ -1,41 +0,0 @@ -There's a lot of talk about what is or what is not DevOps, and I'll -throw my opinion in the mix. - -Until a few weeks ago, at [[http://saymedia.com][work]], we had mostly -two teams: the engineering team and the ops team. Our workflow was (to -simplify) the following: - -- engineers develop services and applications -- they push their change to Jenkins -- a build pass and is pushed to CI -- a few times a week, engineers ask Ops to push the change to - production - -There's already a lot of articles about the kind of frictions created by -this (who owns what; engineers would blame ops when the push was failing -(or the other way around); it's hard for ops to know what's wrong when -something is broken in production; etc). - -A few weeks ago it was decided to create a new team to improve engineers -efficiency, and the team was named "DevOps". At first I was not sure it -was the right name for this team, but now I don't think it matters. - -I was not sure the name was appropriate because of this -[[http://continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/][article]] -(and a few other to respond), explaining why you don't want a DevOps -team, but instead you want the whole organization to be DevOps. We need -engineers to own their applications, to be able to push when they want, -but also to monitor, know what's wrong or slow, etc. - -The *work* [[https://github.com/hachi][hachi]] and I will have to do is -to help engineers and ops to /be/ the DevOps. Our team responsibility is -to choose, evaluate and integrate tools. We will also provide libraries, -documentation, training and support. /We/ are not the DevOps. Our -*goals* are to create this culture, to give more responsibilities to -engineers, and to free Ops from the work of pushing code. The *success* -of this team will be measured by the adoption of our work by engineers -and ops. - -So yes, I agree that you don't want a dedicated DevOps team, but you -still need a team coming from different background (hachi is coming from -Ops and I'm an engineer) to build that culture. |