By Richard Lander, CTO | May 24, 2024
Since I work on software delivery every day, I tend to use the term a lot. I've noticed some people's eyes glaze over when I use these words and I've even begun avoiding it to prevent confusion.
If you search online for a definition of "software delivery" or ask ChatGPT, you'll get conflicting answers and likely wind up more confused than when you started. You'll find definitions that sound exactly like the "software development life cycle" and some that sound just like a definition for "deployment."
So in this post, I'll demystify what "software delivery" means and cover some related terms for comparison and clarity.
Related Terms
Software Development Life Cycle
The software development life cycle (SDLC) is pretty well defined. It is the end-to-end process for bringing a software product to market from inception to end user consumption. It deals with the operational steps needed to bring a software product to market. You'll find slight variations but the term generally encompasses requirements gathering, planning, development, testing and quality assurance (QA), deployment and ongoing maintenance. It is often correctly characterized as an infinite loop that repeats for every new release of a software product.
In auto manufacturing, the SDLC is analogous to bringing a new line of automobiles to market. A new car is first designed and sometimes prototypes are subjected to driver and market testing - similar to a software POC that may be built during the design phase. Then the automobile units must be built and assembled, pass through QA, and get transported to dealerships to be purchased by consumers. Dealerships usually perform routine maintenance on the cars they sell and if there is a recall on some component (similar to a software bug), they replace that component for the car owner.
Software Deployment
Deployment is one of the steps in the SDLC and refers to the installation of software in its runtime environment. When you deploy software you start the software running in an environment where end users can access it. This can also refer to an update to an existing piece of software since the process is very similar. When you "deploy" an update, you're simply installing a new version of the software over the old version in its runtime environment.
To revisit our our manufacturing analogy, this step takes a finished automobile from the factory, transports it by road, rail or sea to a destination where it is put in a lot or on a showroom floor until someone buys it and takes it home.
Software Release
Releasing software is making a finished product available for deployment. In practical terms, software is released when a version of a piece of software appears in the "Releases" section on GitHub, GitLab or whatever development platform you use. A release is a deliverable artifact that can be transferred over a network to a runtime environment and started. In cloud native terms, that deliverable artifact is a container image. But it also could be a binary or some code for an interpreted language. It could also be a complete machine image that includes the latest software product installed with its immediate OS level dependencies.
Some organizations refer to QA's approval step as a "release" step. This can lead to confusion as the software must be released before it is deployed to a QA environment for final approval to be deployed to production.
Delivering Software
Delivering software can be thought of as everything that is needed to deliver a release of some software to an end user. This includes but is not limited to deployment. It includes the maintenance step of the SDLC but includes much more than simple maintenance.
Deployment
This step in software delivery is pretty self-explanatory and is covered above. It includes the installation and starting of the software in a runtime environment. A software delivery system must include support for deploying to multiple environments. Dev teams need development environments, QA teams need staging or QA environments. And, of course, it must ultimately be deployed to a production environment.
An important component of deployment is dependency satisfaction. Too often, this is divorced from the deployment of a software release. It is not useful to deploy some software if its dependencies are not available. Some dependencies can be satisfied at deployment time. A container image or machine image will include the immediate OS dependencies which include packages and libraries. But it will not include the support services, managed services or other dependencies that are installed somewhere else on a local network, as with a distributed software architecture - or microservices. Today, this is a gaping hole in the state of the art for software delivery. It is commonly driven by organizational processes among different teams. A platform team may be responsible for the common dependencies and support services. Dedicated subject matter experts may be responsible for app stack dependencies such as databases. And infrastructure teams may be responsible for the services delivered by a cloud provider or other managed service provider. This often leads to a lot of coordination, toil and delay.
Approval
Automated testing should be a part of every CI pipeline that runs before a software release is produced. If your automated testing is sufficiently mature and comprehensive, this human approval step may not be necessary. However, if your product is like many where human approval is an indispensable part of the delivery process, this is a critical step. Before being promoted to production, a release must be deployed to an environment where QA can perform manual tests and confirm that bugs are fixed and that features are working as designed. When QA is satisfied, they can approve it for production use. Therefore, any software delivery system should accommodate this step into the system, including the concept of promotion of versions from one environment tier to the next.
Observability
Running systems need monitoring, alerting, log aggregation and storage. And they need systems whereby operations teams and developers can access this information readily to preempt issues, diagnose problems and respond to them. A software delivery system must include systems for observability for teams to manage the software their end users consume.
An often-overlooked component to observability is using this data collection in systems that remove the need for common manual interventions. One example that is relatively common is autoscaling which takes compute consumption metrics and scales capacity to meet demand. But this can be done with any data that is repeatedly used to make particular decisions. This is very important to managing software delivery with optimum reliability and minimum human toil.
Updates & Upgrades
Once an initial deployment of your software has been completed, your journey has just begun! There will be bugs to fix and new features to roll out. As such, any software delivery system must support the installation of new versions to replace the old.
Rolling out a new version of one piece of software is normally not too complicated if a simple in-place update is safe. However, some critical changes warrant a blue-green upgrade to make the roll back path more reliable in the event of a problem. And some cases call for a canary deployment strategy so that you can gradually increase traffic to the latest version to ensure all goes well before sending all your user traffic to the latest and greatest release.
And again, dependency management is a critical consideration. If the new version of your software now relies on features in the latest version of the database it uses for its persistence layer, that database upgrade will have to coincide with the upgrade to your software. If it depends on a new service in a microservices architecture, that will have to be accommodated as well.
This is where software delivery can get particularly involved and complicated. Manually juggling such advanced roll outs can be stressful and very prone to mistakes. There are a lot of moving parts and is far better served with software systems that manage advanced delivery. This is large part of why Kubernetes has become so popular as it offloads important roll out tasks to the Kubernetes control plane. This is a huge help in the scope of one particular software release, but further abstractions are needed to orchestrate the support service and managed service dependencies that must be coordinated together.
Threeport
Threeport is an application orchestration system that is designed to incorporate all elements of software delivery into a control plane. It manages all dependencies for software delivery, from the cloud infrastructure, to the Kubernetes runtime environments, to the support services installed on Kubernetes, to the managed services that your app relies on as a part of its stack. The Threeport control plane is designed to orchestrate all the connections necessary to deliver your software. It is extensible so that any custom software architecture can be incorporated and managed with software controllers, rather than stressed out operations and dev teams.
Qleet
Qleet offers managed Threeport control planes so that your team can focus on your core competency and let the team that built Threeport provide the software delivery capabilities it offers.
