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.
4 Comments