Mass convert all posts from markdown to org.

1 files changed, 41 insertions, 0 deletions

diff --git a/posts/2012-12-16-about-devops.org b/posts/2012-12-16-about-devops.org
new file mode 100644
index 0000000..d02674c
--- /dev/null
+++ b/posts/2012-12-16-about-devops.org
@@ -0,0 +1,41 @@
+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.