# Package Management conflicts Continuous Delivery

DevFeed: [Package Management conflicts Continuous Delivery](<https://devfeed.tech/articles/package-management-conflicts-continuous-delivery-31976.md>)

Original publisher: [Read original article](<https://tech.finn.no2013/06/26/package-management-conflicts-continuous-delivery/>)

Author: mick

Published: 2013-06-26T20:42:28Z

Content type: article

Language: en

Sources: [Finn.no](<https://devfeed.tech/sources/finn-no.md>)

Topics: [Package Management](<https://devfeed.tech/topics/package-management.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>), [Continuous Deployment (CD)](<https://devfeed.tech/topics/continuous-deployment.md>), [API](<https://devfeed.tech/topics/api.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [api-design](<https://devfeed.tech/tags/api-design.md>), [continuous-delivery](<https://devfeed.tech/tags/continuous-delivery.md>), [continuous-deployment](<https://devfeed.tech/tags/continuous-deployment.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [package-management](<https://devfeed.tech/tags/package-management.md>), [transitive-dependencies](<https://devfeed.tech/tags/transitive-dependencies.md>)

## AI overview

The article examines tensions between package management and Continuous Delivery. It explains that package releases cannot be undone once downloaded, whereas deployment changes can be rolled back, while API design and modularity limit how far Continuous Delivery can be applied. It proposes emphasizing safety and API design lower in the stack and delivery speed higher in the stack.

## Source excerpt

The idea of package management is to correctly operate and bundle together various components in any system. The practice of package management is a consequence from the design and evolution of each component's API. Package management is tedious but necessary. It can also help to address the 'fear of change'. We can minimise package management by minimising API. But we can't minimise API if we don't have experience with where it comes from. You can't define for yourself what the API of your code is. It is well beyond that of your public method signatures. Anything that with change can break a consumer is API. Continuous Delivery isn't void of API despite fixed and minimised interfaces between runtime services, each runtime service also contains an API in how it behaves. The big difference though is you own the release change, a la the deployment event, and if things don't go well you can roll back. Releasing artifacts in the context of package management can not be undone. Once you have released the artifact you must presume someone has already downloaded it and you can't get it back. The best you can do it release a new version and hope everyone upgrades to it quickly. Push code out from behind the shackles of package management take advantage of continuous delivery! Bearing in mind a healthy modular systems design comes from making sure you got the api design right - so the amount one can utilise CD is ultimately limited, unless you want to throw out modularity. In general we let components low in the stack "be safe" by focusing on api design over delivery time, and the opposite for components high in the stack. High in the stack doesn't refer to front-end code Code at the top of the stack is that free of package management and completely free for continuous deployment. Components with direct consumers no longer sit at the top of the stack. As components consumers multiple, and they become transitive dependencies, they move further down the stack. Typically entrop