DevOps is a software development and delivery process which considers the production of software from end to end, from concept to design, delivery, deployment and maintenance. DevOps is a broad software development process, which normally includes an Agile approach to delivering a sequence of software development builds, but also deployment and testing. All the stakeholders involved in developing the product are included: product managers, development teams, quality assurance testers, system administrators and end users.
But why expend the time, energy and money to implement a comprehensive DevOps process? If the end goal of an organization is to deliver the highest quality, best value software products in a consistent, repeatable manner, then implementation of a solid DevOps process will be worth your investment. To successfully implement DevOps in an organization, a change in culture and mindset is required because DevOps is largely about implementing new processes to accomplish the mission. This means removing barriers that typically exist in any organization in order to fully integrate the roles of development teams and operations, maximizing the efficiency and precision of the software development process.
In a fully implemented DevOps culture, team members view the development lifecycle as their responsibility, with each playing their individual roles within the context of the DevOps process. This is akin to a musician. The musical score is their product, but they each play their role within the structure of the orchestra to deliver a quality product for the audience. Like the orchestra, DevOps emphasizes collaboration and communication among members of the team, who all play nicely together, following a well-defined process.
In a well-conceived DevOps environment, software is built, tested, released and deployed more rapidly, frequently and reliably than with other approaches, due to the well-conceived and highly refined processes, scripts and management employed to execute the entire operation.
Implementing a DevOps culture requires an initial investment of time and training and ongoing investments to maintain the processes. So why make these investments? It’s all about developing quality software. Whether you are developing SaaS applications for general use among a diverse international population, or working for a software development shop, coding a wide variety of applications for your customers, developing a quality product should be your primary goal. A solid DevOps process will carry you a long ways toward that goal. A quality software product can be measured in many ways, functionally, financially, culturally and reputationally. Remember, DevOps is also about involving a universe of stakeholders in the development process. With DevOps, reliable software is released faster and more frequently. Time to market is not only improved, but made more predictable, improving the product’s competitive position, and delivering for your sales team. The time from the creation of a requirement or user story to the time the feature is realized in an application is reduced, reducing cost and meeting critical milestones. If a nasty bug is discovered, the time to implement a hot fix is diminished.
There are no standards that define an ideal DevOps process. Project budgetary or labor constraints may limit the DevOps components that are implemented in a specific project. For instance, it’s usually not feasible to implement automated regression testing in smaller projects as the return on investment falls short of goals. But that same small application could surely benefit from a micro services architecture or continuous integration. A skilled project manager will work with stakeholders to ferret out which DevOps components make sense for each project. And while it’s not really feasible to implement a comprehensive DevOps process all at once, an incremental approach will be easier to manage, yielding significant improvements that can be added to at a later date. The following components can be implemented in a DevOps process.
For greenfield software development projects, you may want to consider implementing a microservices architecture. A microservices architecture is a collection of independent modular services that communicate with each other, typically via HTTP/REST. This approach improves scalability, reliability and flexibility while reducing interdependencies. The clean architectural break between microservices leads to easier QA testing. The microservices architecture nicely mimics the cloud service architectures that these applications interact with and reside in. Scalability and flexibility are built-in benefits that may assist the application as customer functional and throughput demands modulate over time.
If you have an existing product, the transition to a microservices architecture might not be practical as a major refactoring of the code may be necessary. However, I have seen ancient COBOL applications wrapped in web API components in order to extend the life and improve the reach of software that would otherwise require a huge investment to refactor. Sometimes it all comes down to a cost/benefit analysis.
This component is often realized in the form of an Agile software development process. Software is delivered in small iterations, encapsulated in Agile sprints. Because the changes are smaller, it is easier to isolate and resolve newly introduced bugs, which is a less risky approach. The concept of minimizing risk and identifying problems early is at the core of DevOps.
Rapid delivery is not merely confined to frequent, small builds. A major goal of DevOps is to automate the software delivery process as much as possible. Builds, integration, testing, deployment and logging can all be automated — greatly improving reliability of the product while improving development velocity. As mentioned earlier, it is not always feasible to introduce high levels of automation on every project, particularly smaller projects.
DevOps automation and risk management can be applied to the build process. This is one of the easiest and most effective ways to reduce bugs and eliminate code integration issues, especially on larger development teams. Every time a developer checks in code, it is automatically deployed to a build server, where an automated build is executed, which could include automated testing. Any resulting bugs are reported to the development team for consideration.
Continuous delivery involves automating the release process so the application can be automatically deployed at any time. In DevOps, when the code passes continuous integration testing it should be automatically deployed to a test environment. The test environment should mimic the production environment and therefore be automatically refreshed before each deployment to assure a clean target. Once the build passes automated or manual QA, it is may be deployed to a staging environment that is identical to the production environment (as opposed to the test environment that is similar but has all the QA tools installed).
A final test on the staging environment assures there are no deployment issues, then the application is deployed to production. This migration of the build from server to server, with the server provisioned each time in advance of the move would typically be the responsibility of Operations. In the DevOps world, Operations and Software Development would plan this process together and implement Infrastructure as Code (IAC), greatly improving the likelihood of an efficient, reliable and smooth automated delivery process.
Ideally, software testing in the DevOps world requires an automated test process that provides feedback at every checkpoint. Integration testing is needed on the build server. Functional testing, regression testing and more are needed on the test server. Deployment testing is needed on the staging server. If the build passes, it advances to the next step. If it fails, errors must be fixed before the process can continue.
Granted, it may not be possible to do every type of testing. Resource constraints frequently limit a team’s ability to implement DevOps. Test automation takes time, is expensive, and it’s rarely possible to automate every conceivable test. For this reason, it’s practical to define an automation strategy. It may be possible to restrict automated test development to critical core areas whereas peripheral functionality can be tested manually. And if you are using automated testing, it’s best to keep your test scripts under version control as with the application software.
Remember, the goal of DevOps is to deliver quality software products, and your customers and end users will let you know if you don’t hit the mark. Newly developed and deployed software will always have issues as unforeseen circumstances will be revealed. They call them exceptions for a reason! A well-architected software product will contain built-in mechanisms to capture exceptions and record them in a repository that can be monitored in real time as the application runs in production. Performance and resource issues can be monitored as well and any issues can be triaged by the project team to determine if and when corrective actions will be taken, ideally before it becomes an issue with the customer.
When developing a software application, DevOps may not be as exciting as developing the software components, but it is equally important in ensuring the success of the project. Anybody seeking to engage a software development partner should ask about their DevOps processes. They should be able to clearly articulate their DevOps strategy and overall plan for your project as effective communication will be critical throughout the development cycle. You want to choose a partner who has demonstrated success in Agile development and can help foster a true DevOps culture within your organization. By choosing a partner that takes a holistic vision of your project and employs the agile development methodology to address your biggest business needs, you can help ensure success for your next custom software development project.