DevOps amplifies your open source credentials | Opensource.com

DevOps amplifies your open source credentials

Posted 10 Apr 2014 by 

Rating: 
(3 votes)
open source experience
Image by : 

opensource.com

submit to reddit

Can you really do DevOps without sharing scripts or code? DevOps manifesto proponents value cross-functional teams, symbiotic relationships, and continual feedback loops. Effective DevOps initiatives create engaged communities where team interactions amplify personal actions. When technology teams find adopting a DevOps culture is more difficult than using DevOps tools, suggest the open source way as a path forward.

By adopting the open source way, DevOps initiatives can bridge gaps between team members and build internal communities based on open exchange, participation, rapid prototyping, meritocracy, and common purpose. Jen Krieger provocatively proposes that 'you can’t have DevOps without open source'. Jen make powerful points: an open source culture embracing sharing, visibility, and joint goals brings people together, socializes individual contributions, and improves DevOps team performance.

Lead architects and development managers can help create a DevOps culture by sharing ideas, team activities, and challenges.   When I was a development manager, I found team members often faced similar challenges. By simply sharing a framework, code snippet, or tutorial crafted by a team member, I was able to accelerate project delivery and enhance the personal brand of the person who blazed the path forward. When teams adopt the open source way, 'getting something done with DevOps' becomes 'getting something done faster' by re-using pre-built provisioning scripts, virtual machines, and code created using DevOps principles and practices.

Managers and directors leading successful DevOps initiatives systematize sharing, collaboration, and feedback. In addition to continuous delivery with Jenkins and Puppet (or Chef), build collaboration and visibility across the entire development life cycle. Self-service project creation, open project dashboards, open bug reporting, and project forums create a collaboration space that increases team member visibility, demonstrates project momentum, and encourages re-use. By adopting an open source feedback loop based on delivering code, receiving input, and rapidly releasing enhancements, teams can become the trusted solution provider of choice.

Proponents position DevOps as a means to 'quickly ease the project pain'. Small collaboration improvements do bridge the pain gap between requirements and delivery. To bridge the pain gaps, DevOps practitioners often focus on ‘infrastructure as code’, ‘continuous delivery’, and automating activities. Balance DevOps rapid prototype works with a managerial focus on team collaboration, reducing effort, and adopting pre-built building blocks. Enterprise architects can increase their relevance by working with developers and operations to create re-usable, pre-built solution accelerator packs (i.e. base virtual machines, standard cloud environments, shared policy enforcement frameworks, and provisioning recipes).  Enterprise architecture can be the bridge between embedded project requirements and shared DevOps solutions.

When 'doing DevOps', don’t only build infrastructure as code and automate activities. Encourage cross-team communities, amplify personal contributions, and promote emerging solutions. These three DevOps success actions are also the core of effective open source.

By incorporating the open source way into your DevOps transformation, you increase DevOps effectiveness, promote individuals, and enhance everyone’s open source credentials. If individuals hesitate to jump in, share ideas, experiment, and contribute, recommend 10 ways to participate in open source. These ideas apply to DevOps too.

 

submit to reddit

4 Comments

Anuj Sharma

The power of a dev environment comes from many places. First is time saved by reducing the number of manual steps and by preventing context switches for a developer. Improving flow enables a developer to catch bugs sooner when they’re still inexpensive. Consequently, moving toward continuous testing and integration is essential. In this post, we’ll discuss a continuous integration workflow using opensource tools.
http://flux7.com/

Vote up!
0
Vote down!
0
cobiacomm
Open Minded

Hi Anuj, you provided a link that does not goto a post, but simply references the main corporate home page. I do like the blog entry posted by Aater (Flux7 CEO), which focuses on developer workflow. http://flux7.com/blogs/devops/dissecting-effective-developer-workflows-t...

The team at Flux, and others, may be interested in an opensource DevOps PaaS (e.g. WSO2 App Factory) that integrates development workflow activities with operational activities and cloud instance deployment.

Vote up!
0
Vote down!
0
jkrieger
Open Enthusiast

Chris - got any pointers on how to address when it is bad code that is being shared? :)

Vote up!
0
Vote down!
0
cobiacomm
Open Minded

Hi Jen, Sharing bad code is just, well, bad! Automated tests executing on a code commit pre-hook can help identify bad code (before the code works it's way into the central repo). With distributed version control systems, the team can structure a development process whereby code must migrate across several gates and undergo human review, static code analysis, integration tests, and regression tests before gaining enough release karma.

Vote up!
0
Vote down!
0

Comment now

Chris Haddad (aka cobiacomm) is Vice President Technology Evangelism for WSO2, an open source Cloud Platform vendor. Chris has been hacking Apache open source since 1999, and gained committer status on the Apache Axis project in 2003. Chris is a former developer, architect, consultant, and research leader whose goal is to encourage DevOps, Big Data, Platform as a Service, and Cloud Architecture best practices that maximize your business value and agility.

What Docker 1.0 means for OpenStack