Why do dependencies in today's decentralised software ecosystem create risk, and how does that motivate automation?
Applications are assembled from many independent components whose authors can drop old features at any time, so dependency-heavy stacks become fragile and increasingly insecure unless they are rebuilt and tested automatically.
Modern software is not built by one vendor. Developers mix libraries, services and infrastructure from many sources, and that brings three risks:
- Components must be generic. A component has to work with many others in many situations, so it should prefer a particular partner component or architecture only where it really has to.
- Support disappears. A component's maintainers may drop a deprecated function or a rare integration. Any process that depended on it breaks.
- Stacks get stuck. Configurations tangled in dependencies end up in fragile deployment stacks that nobody dares to touch, so they stop receiving updates and become less secure over time.
The link to automation is that you can only keep up with constant upstream change if rebuilding, reconfiguring and retesting the stack is cheap. When it is a manual effort, teams freeze versions to avoid the work, and that freeze is exactly the fragility described above.
Go deeper:
Continuous delivery — Wikipedia — why cheap, frequent rebuilds keep dependency-heavy stacks from freezing.