New approaches to software development also mean new challenges.
Software development changed radically with DevOps -- practices that combine elements of development and operations. The traditional approach, involving major and infrequent updates based on long development cycles and significant testing, often resulted in user dissatisfaction or frustration. The DevOps approach -- releasing smaller, more frequent updates -- reduces errors and strengthens the critical relationship between software engineering, quality assurance and IT.
DevOps practices promise to alleviate the silos and communication gaps that usually exist between software engineers, IT, QA and other parts of the business. DevOps should create complete transparency within the business to facilitate agile planning and prompt decision-making. So, as the organization integrates DevOps, avoid creating new silos, like a separate DevOps team.
Traditional long-cycle software updates provide significant changes and additions, which can create substantial bugs and unforeseen consequences. The subsequent release is months away so these bugs won't be addressed quickly. Long-cycle software development often fosters a disconnect between the business and software team; business goals change and software design goals don't change with them. The software product might never fully meet the organization's goals.
DevOps projects must identify and align with business needs -- always ask why you're taking up a DevOps approach and what success will look like. For example, if the business is losing customers fed up with bugs in the software, a DevOps specific goal will be to shorten the cycle to fix bugs or grapple with fewer bugs in each new release, improving customer retention.
The short cycle times used in DevOps projects allow ample opportunities for feedback and to measure success. A DevOps paradigm can fall short of expected results when the criteria for success is not measured or reviewed frequently. In the example goal of fixing bug problems, decide how to measure the criteria for customer retention and/or satisfaction and then review those metrics regularly to gauge the success of adopting DevOps. Organizations will quickly see what is and isn't working and can make adjustments to improve results.
IT organizations built on traditional development practices experience roadblocks when adopting DevOps. Consider a project-by-project approach to DevOps, rather than a sudden and complete shift. Start with less-critical projects, identifying and correcting organizational roadblocks as they emerge. As the company culture and processes adapt to accommodate DevOps practices, the paradigm can be applied to more important and high-profile projects.
DevOps is more about project management than it is about particular software languages or platforms. Software engineering, IT, QA and many more groups have to collaborate. Current software and organizational tools generally work fine to start. As DevOps projects scale out and become more frequent, many additional tools can improve your organization's approach:
- Git and GitHub provide code repositories that support version control and downloading.
- Perforce Software and similar vendors provide a revision control system for software development.
- Testing code can be handled through tools like open-source Jenkins.
- Nagios or Sensu monitor the ways that code changes impact the environment.
- LogStash can parse log entries to help developers see how code is performing.
- Main configuration management platforms, such as Chef, Puppet and other platform options, can be augmented with tools like Berkshelf, which fetches and deploys cookbooks to Chef. Similarly, tools like Test Kitchen Vagrant can run Check cookbooks without disrupting the Chef server -- easing cookbook development.
This is only a small sampling of tools that will augment DevOps practices. There are countless other options, so test and evaluate options depending on your organization's specific goals and requirements.
Is cloud computing a required DevOps element?
DevOps success stories
With traditional software development, new versions are rarely tested in full production environments. Chronically, functional or performance oversights go unnoticed in the development environment without real-world conditions to expose them.
DevOps developers successfully use private or public cloud to create more complex environments that simulate production use for version testing. The scalable, self-service nature of cloud computing allows developers to provision and migrate new versions for testing with little -- if any -- reliance on IT administrators. This makes testing faster and simpler than traditional provisioning requests to IT.
Public cloud is usually preferable because it offers high scalability and self-service without any danger of exhausting local IT resources. When testing is complete, the public cloud resources can be released to save money until the next testing cycle starts.
Now that you have an idea of how to start out with DevOps practices, take the DevOps quiz to gauge your proficiency.