DevOps for Lean/Agile modle Vs Traditional model.

[meenakshi sundar]

I understand DevOps is more suitable for lean/Agile product development world than more traditional services based consulting companies

I am coming from the background of Consulting/service based industry as opposed to product based
How do i bring in the shift in my world if we wanted to experience all the good things that DevOps brings in,Would it add any value to it?

[Tim Holloway]

As a consultant you wouldn't be expected to do DevOps duties yourself. But you should get familiar with some of the tools that DevOps people work with. It's likely that you might be called on to help develop provisioning support for the apps you are developing, so learning Puppet, Chef, and their friends would be a good idea.

And, while I don't myself consider continuous-integration systems such as Jenkins to be DevOps, strictly speaking, that's another tool that it's good to know how to tweak so that when it does its thing, the results will be more DevOps-friendly.

[Darrell Rials]

Tim Holloway wrote:And, while I don't myself consider continuous-integration systems such as Jenkins to be DevOps, strictly speaking, that's another tool that it's good to know how to tweak so that when it does its thing, the results will be more DevOps-friendly.

I'm in the same situation as the original poster. Anyone care to define "DevOps-friendly"?

[Tim Holloway]

Products like Jenkins can deploy directly, which would make them a DevOps tool. Or, if you prefer, they can build stuff for handover to a separate DevOps person/team. So by "DevOps friendly" I mean things like setting up the Jenkins builds to produce installable packages and modules as opposed to raw products (such as WAR files).

[meenakshi sundar]

Hi Tim

The intent of my original question was to understand besides all these tools,on the process side ,I am sure there are certain things to be taken care of,I am looking for those.
Thanks

[Len Bass]

Tes 0 tgere are kits if things to take care of both on the process side and the organizational side. We have a chapter in our book that describes how one builds a business case for DevOps and another, case study, chapter about an organization that implements continuous delivery pipelines. These chapters will answer some of your question. What it leaves out are the cultural issues. These are covered in LinkedIn DevOps groups among lots of other places.

[Liming Zhu]

@meenakshi, tools often change culture/process. And DevOps practices do need some level of culture and process change. I have seen consultants promoting DevOps and continuous deployment using tools to impact culture/processes directly.
The book talks about small teams, communication through interface "only" and applying agile and SE principles to operation side in the early chapters.

[meenakshi sundar]

Thanks @Liming @Len

Just a last thought on the books title, why its been specifically named DevOPS "A software architects perspective",is it also not the prerogative of the project manager/Product manager
who are in a way owner of the delivery,Do you have anything specific for these roles as well in the book?

Thanks
Sundar

[Len Bass]

We called it "A Software Architect's Perspective" because we are software architects and that is what we bring to the party. The target audience are architects and developers who are wondering how DevOps will impact them. There is a chapter on building a business case that should be of interest to project managers but the book by Humble and Farely on continuous delivery is much more targeted to project managers.