Necessity of Continuous Delivery in Business Software

Necessity of Continuous Delivery  in Business Software

Custom software as an industry has been around for over 30 years and, as such, has seen its fair share of variation and divergence in methodology. Some things tend to be consistent across the industry while others are anything but. The basic players, or stakeholders, tend to be rather predictable. There is the sponsor requesting and paying for the outcome of the work, their possibly-internal customer who will hold ownership and oversee use of the outcome (generally termed the Product Owner), the team doing the work, and the individual who is orchestrating, facilitating, or managing the work. The methodology in performing such work, as well as the availability and willingness of the owners of the business information and project outcome, can be just as varied as the types of software we are being asked to create.

SDLC Paradigm Shift

Continuous Integration Continuous Delivery

Methodology in how projects are carried out evolve like languages. Core methodologies carry great breadth over a long period of time and produce many branch-off methodologies and specific-focus applications, many of which merge back into the truck evolving it further

Accelerations in technological advances have resulted in a higher degree of exploration present in many projects, as most projects can no longer be described as doing what many others have done but doing it for ourselves. Technological offers which are cutting edge and first-to-market are now paramount.

Corporate culture is also evolving, among other ways in the mobility of employees, not only within but even without an organization. All but gone are the years and days of named individuals dedicating entire careers to a specific product, process, or organization with no intention or desire for anything else. There may not be a specific individual, or perhaps even any individuals, holding all-inclusive ownership over the software that is to be made.

This higher degree of discovery, coupled with the distribution or dilution of ownership, have affected an increasingly more abstract working environment for software teams. Whereas the vast majority of software development efforts in decades past followed the linear, single-flow Waterfall methodology, more and more projects and organizations are adopting the Agile methodology for its ability to accept and incorporate change and its tolerance for and embracing of uncertainty.

The DevOps Movement

There is a wealth of information on what has come to be known as DevOps, essentially the marriage of development and operations within an organization. DevOps aims to shorten the system development lifecycle by removing the departmental walls between verticals within an organization. Doing so allows for a truly cross-functional team where differences in skillset within an immediate team grouping go beyond differences of technology to different areas of practice within the overall company.

The point that is to be taken from this (for our immediate purposes) is that the Product Owner within a development team is usually not from the Information Technology department at all. In most cases, they are departmentally from the Operations vertical, or perhaps even Marketing or Compliance. Eliminating the cross-department barrier and allowing their direct basis in and membership on the team doing the software development work eases innumerable burdens for communication, progress, and efficiency.

Continuous Integration Continuous Delivery

DevOps Illustration

The primary technical artifact given rise by the DevOps movement is Continuous Integration Continuous Delivery (CICD). The primary non-technical artifact given rise had been the inclusion of the non-IT-department Product Owner in the team. This process approach is fundamental in supporting rapid incremental progress in environments where progress “needs to be seen” regularly and where uncertainty is high, and requirements come through progressive elaboration.

The integration aspect of CICD is not so different from the standard practice of having an integrated development environment. While any number of developers can technically be working on separate features in parallel (and in isolation in their own development environments), the real test of their work is when a completed piece of added functionality is merged into the aggregate lower environment to ensure that it (1) still works in the context of the full system, and (2) other parts of the system do not begin malfunctioning with its introduction. This is regression testing and is the primary catch-all testing that can cover for misses in unit tests and functional spot testing while also providing additional system-as-a-whole coverage that those two do not.

Delivery is the act of making added value available to the Product Owner, effectively serving the new functionality to them to do with as they please (although, really their only options are release and wait). This is generally realized as a code push to a dedicated pre-Production environment and may come before but usually falls after User Acceptance Testing in a Staging environment.

Deployment is often inappropriately thought to be the “D” word in CICD but there is an important distinction to be made between the delivery and deployment. While delivery is the presentation of a value-add (feature/enhancement) as complete, deployment is releasing it to active use by the user population. Depending on the process established in an organization, delivery and deployment may coincide. For larger systems, delivered increments may be aggregated into a smaller number of releases. In Scrum terms, delivery refers to the functionally complete increment at the end of every sprint, and deployment is specifically referencing Production releases which may take place after every second or third sprint, rather than with each one.

Continuous integration as opposed to integration and continuous delivery as opposed to delivery are matters of process automation. This most crucial aspect of CICD underlies the machine and process efficiency of the team. A finely tuned workflow enables seamless progress by developers, testers, and user agents from one task to the next. Continuous Integration facilitates an automatic gated build and deployment of newly-completed-and-checked-in enhancements, automatically notifying the testing team and ensuring them at least a basically working codebase and environment. Continuous delivery personifies the spirit of Agile by providing a usable, value-adding Increment with every iteration.

Conclusion

DevOps itself continues to evolve with integrated CICD ensuring rapid completion with transparency and functionality. This higher performance means you can work smarter not harder. With everchanging DevOps possibilities, your options are limitless.

Code Authority practices modern DevOps by implanting a CICD pipelines into each of our software projects for quick and efficient product delivery. Our software development team will work with your business to make your concept a reality. Contact us today for a free consultation!