DevOps amplifies your open source credentials

No readers like this yet.
open source work experience

Opensource.com

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.

 

Chris Haddad @cobiacomm
Chris Haddad (aka cobiacomm) helps reshape IT delivery by introducing disruptive open source projects, refreshing technology platforms (think Cloud-Native), rebuild team interactions (think DevOps), and re-invent opportunity (think APIs).

4 Comments

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/

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-to-save-time-lower-costs/

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.

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

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.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.