DevOps tools and processes
VidhyaV 270001DB84 Comment (1) Visits (12491)
Customers today are demanding, and getting quicker responses to product feedback. Software versions released at an ever brisker pace reflect the urgency with which firms are treating customer demands. How does a firm handle the challenges that these heightened expectations bring up? What are the tools that it should acquire to manage the complexity?
Typically, a software delivery chain consists of a source code version succeeded by a sequence of binaries deployed successively in various test environments, leading up to production and final release. Feedback from the customer is channeled back to the source code, and the series of builds repeated, resulting in a new version of the application. Until recently, customer expectations did not demand frequent releases, and operations could afford to focus on one stage of the delivery chain at a time. An application was at one time in one stage only - in the ‘development environment’, or in the 'test environment', or in a 'staging environment', or released to production or customer. Managing the software delivery chain was relatively simple, and most of the effort was focused on making sure that the current build did not fail.
Today, this image of ‘unchanging’ software is waning. The trend is to release incremental changes frequently and before a competitor can do so. Not surprisingly, the complexity of managing the software delivery cycle has increased exponentially. With several versions going out in a week, or even a day, it is no longer a single cycle that needs to be managed, but many cycles. Multiple applications in different environmental stages need to be developed, stored, tracked, tested, and deployed. Since releases are so close on each other’s heels, slippages at any stage could delay not just the current version but all subsequent versions.
Organizations whose business imperatives demand such frequent software releases will find it useful to embrace DevOps. Last week I wrote about DevO
The usual tools for software project management, source code management, integrated development, and testing, are of course necessary and are very much part of every DevOps setting. However, a few other areas need new tools or strengthening of existing ones.
Component versioning and tracking is one of the treacherous areas. As a complex product usually has many components, each of which can exist in several versions, manually tracing component versions to their corresponding product versions is not feasible. DevOps tools which can map component versions to product version simplify the process of readying an application package for deployment. They go a long way in reducing build errors caused by incorrect components.
Managing the deployment process is even trickier. Large applications usually have to be tested on various servers, databases, and middleware (collectively called environments) before being cleared for release. The process of tracking which applications are in which environment is of course a complex task. What makes the task more complex is the need to have multiple environmental configurations, and track and record each environment configuration and the corresponding build version. Tools that track build versions, and map the corresponding environment parameters are critical to any DevOps setting. Some DevOps tools go a step further and even provide the workflow required to promote the builds from one stage to another. IBM
Environment provisioning is another area impacted by these new trends in software development. With so many builds simultaneously active, firms may need hundreds of servers at a time. Obviously virtualization technology with its advantages of cost and flexibility finds favor with firms. Tools that help automate the provisioning of virtual environments are therefore a core part of most DevOps scenarios.
As DevOps styles of functioning become more popular in the software world, the range and sophistication of tools and processes is bound to increase.