Why You Need a Software Delivery Machine
This video is also available in the GOTO Play video app! Download it to enjoy offline access to our conference videos while on the move.
Many teams have a clear vision of how they want their software delivery to work. For example, what checks and staging deployments should occur on commits; what approval steps are required before promotion to production; what code needs to be included in new projects and what provisioning should occur on project creation; and what policies matter around license files and security scanning.
But it’s hard to realize that vision. Typical challenges include:
- Growing proliferation of services, meaning many delivery pipelines that can’t easily be changed as one, and many repositories with dependencies, configuration and usage practices getting dangerously out of date.
- Bringing on new developers, due to lack of effective knowledge sharing and lack of automation
- Creating new projects without copy/paste, leading to wasted effort and inconsistency
- Lack of visibility into the whole elephant. What is deployed where? What is at what version? What is happening across the organization? Who should be informed in the case of a production alert, and to what code does it relate?
The solution to these software problems is more software. These problems can best be addressed together, through greater automation, backed by a model spanning development and delivery. It’s what we call a software delivery machine.