• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

DevOps for Lean/Agile modle Vs Traditional model.

 
Ranch Hand
Posts: 201
1
Python Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Bartender
Posts: 20938
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Bartender
Posts: 20938
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 201
1
Python Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Author
Posts: 13
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Author
Posts: 6
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@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
Ranch Hand
Posts: 201
1
Python Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author
Posts: 13
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!