For a month I’ve been breathing Devops heavily through the involvement in 3 Devops-related events:
- A dedicated lab at Devoxx France (Paris) with my fellow Devops Mercenaries – March the 29th
- A Devops Agile Mëtteg organized on Agile Partner Premices - April the 11th
- First day of Devops Days Paris, which I happened to help organize – April the 18th
Let me go through them un-chronologically, in order to make their presentation more logical.
The Devops Agile Metteg was meant as an introduction brainstorming on the concepts surrounding and underlying Devops.
Participants were eager (from what I felt) to learn what Devops is, and were from Dev, QA and Ops teams, with a majority of people from Dev teams.
We tried to build and then to discuss a mindmap of the concepts around Devops.
Some were surprised to see that Devops is neither a “method” nor a set of tools, and I think we all arrived to grasp the fact that Devop is more an alternative prism to existing problems.
That alternative vision helps focusing on extending the benefits of Agile practices (i.e. having Business stakeholders and Development teams focus together on the outcome of I.T. projects) to the whole value stream going from Business stakeholders to Operations, going through Dev teams, QA teams, and Ops teams.
There are definitely tools, practices and possibly methods involved in the mix, though they are not Devops tools, practices and methods, but more existing tools compatible with a Devops approach and vision.
That precise Agile Mëtteg was designed as a brain storming with some guiding support, and would have deserved (after a little internal retrospective) even a bit more guiding given the short amount of time we had and the numerous topics to cover.
Though I think the spirit was good and the feedback from participants ever interesting!
Definitely something to try again, with the same and additional participants in the mix!
Devops Mercenaries at Devoxx France
That exercise was a bit different, because my fellow Devops Mercenaries and myself had already presented a 3 hours introduction to Devops in 2012 at Devoxx France, and the workshop we did this year was a follow-up to that introduction, therefore targeted to an audience already aware with the basics and the specifics of what Devops is (and is not ).
Some of my fellow mercenaries (Henri Gomez and Dimitri Baeli) and I did a workshop for a whole day at Devoxx France on March the 29th.
The purpose was to get participants to express what they felt Devops is, or what they wanted to learn from it, and then elaborate from that, through the discussion and completion of a mindmap (soon to be published on Devops Mercenaries), and through the presentation and discussion of practical examples of practices and tools.
We pushed a bit further what we had done the year before, which was building an end-to-end application with continuous provisioning, deployment and monitoring.
The purpose here was to extend the ownership of all the aspects of an application to all the stakeholders involved. Everybody can work on and try out acceptance and performance scenario, without a specific environment, and therefore contribute to their quality.
That example brought interesting discussions around topics such as Devops culture, native packaging, distributed configuration tools, responsibilities and roles.
If we have the honor to be chosen again, this was an exercise we’d like to try and reproduce again.
Once again in a retrospective exercise, we’d probably keep the discussions more focused, but we had to try it this way in order to gauge how to channel discussions properly.
This was definitely fun and we can’t thank enough the participants, while hoping they had as much fun and got away with as much new knowledge as we did.
Devops Days Paris
I had the honor and joy to participate and help organize a bit the first Devops Days occurrence organized in France.
I only participated in the first day of this 2 days conference, and it was already very full of very interesting feedbacks.
The morning’s presentation were very good, though I must admit a few days after their occurrence, I’m still failing to find a specific highlight on a given one.
We’ve heard about such diverse topics as how to handle Customer feedback, how to turn developers’ mind to devops, how to think about products more than about projects in enterprises, and how ops concerns can improve development.
The highlight of that morning were the ever-entertaining and very fun ignite talks. Those talks are 5 minutes talks, with slides changed automatically every 15 seconds. An interesting and difficult exercise
It definitely highlights (to the extreme) the need for few words, pictures, and no bullet points in slides
The highlight of this day (content wise, see further on for the remaining fun) were the open spaces. Topics were chosen by participants and put on a board for voting, and then various open spaces were created in order to discuss elected topics. The discussions were too deep and numerous to sum up though I’ll try and sum up my feelings globally at the end of this post.
The day ended with a gratifying Diner on a boat on the Seine (with a beautiful view of the Eiffel tower), and an open bar somewhere in Paris.
What did I get from those events
Those events were very different and fulfilling in very different ways.
After the very specialized discussions of Devoxx, the Agile Metteg allowed me to try and get back to the basics, and to summarize what Devops means.
Devops days was an open parenthesis on what the Devops angle brings to thinking the I.T. landscape, and I must say that parenthesis is not yet closed for me .
What Devops is
To begin with, what it is not: a product, a method, a person, or a team.
Those things can (or should) be devops-compatible though.
Devops is more a cultural shift and a different vision and approach to solving already known issues and therefore can seem a bit overwhelming and even “buzzwordy” because it seems everything can fall into its scope .
In the end, few things are really devops compatible in our current I.T. landscape (except if you work in a startup or in a big web 2.0 company). I.T. is often divided in very distinct parts separated by cultural and administrative fences.
The purpose of Devops is to diminish the need for those fences, but not to turn everybody into an anonymous Devops profile. Operation people should still have operations responsibilities and roles, though they should share common responsibility of some things with Customers, Devs and QA. The same goes for other specialized profiles.
The main things that should be shared by all these people are visible dashboards, common live metrics, issue diagnosis and the products themselves. This is not exhaustive, and the most interesting bit is how to put this up, though these are the things I currently think can make up for a good start of a Devops initiative.”