over velocity The team needs time and space to make the changes needed The driver shouldn't be to reduce the TTL A huge change in culture is required The dev team needs both responsiblity and autonomy Developers probably need to be able to decree when something's "done" The developers need to be part of the testing cycle Specifications should be behaviour oriented This approach doesn't work well with micromanagement This isn't a silver bullet. It will not solve your political or technical problems Continuous Delivery will likely increase your ops costs The process initially requires more work and handholding There needs to be commitment from leadership to complete the migration If you can read this you’re too close! This works best for addition-heavy environments This augments good practices, but gives you plenty of rope to hang yourself with if you go rogue Continuous Delivery favours non-destructive schema changes If you're not using version control, you're already screwed You'll need a lot of tests This takes a lot of time, and can't be rushed Getting buy-in from external parties can be really hard This isn't talking about microservices, though there is some common ground I'm assuming you've got good coverage on your codebase, not just happy-path testing The whole team needs to be onboard Regular data migrations may not fit well with CD You need a deployment process which is at least semi-automated If your deployment is slow, speed it up and come back later Your test suite should be quick too. Slow tests can become a bottleneck Your deployment process needs to be stable Leadership need to hand control of deployment to the developers The code quality and PR acceptance processes need to be well defined Half way, we're on to a winner The development and product teams need to trust each other There needs to be a high level of trust within the developers You need to need the cadence of continuous delivery If it doesn't offer any benefit over what you're doing, it will probably fail Other stakeholders in the business need to buy in to the value of the changes It helps if you have tools available which work with your language/framework Complex deployments are harder to automate. Obviously. Your team needs to want to learn. There are lots of new moving parts here Good test coverage is key Increasing cadence also reduces certainty about how the code works This is written from the perspective of a small business with a small development team Shorter feedback loops can increase the development burden in bug fixes / minor tweaks This will not solve your political or technical problems. It's worth mentioning twice Responsibility must be devolved to everyone in the process You need support from ops (if you have an ops team) If you're development cycles are naturally slow, a fast release cycle may not help There's a strong focus on requirements, and you'll need a good approvals process Support teams need support to understand and triage newly emerging bugs and problems The implementation of CD requires strong leadership throughout You'll need more formal testing, which can be hard Did you really get this far? Honestly? If your system doens't change much, CD is probably unnecessary Sales teams need to be involved and buy in to the constantly shifting landscape Without camembert, Ryan may feel sad I've completely omitted a few aspects of dev team culture which are important here Speed of delivery can go down as well as up I really did try to come up with 64 caveats There are many approaches, and this is only one of them Giving up before the end can leave you in a worse state than you started with Almost there You need a strong vision of your goal, and reasoning behind adopting CD
spikeheap
kangnux
konifar
yosuke_furukawa
bkuhlmann
faithandbrave
quramy
shinden
ryunakayama
zsmb
takefumiyoshii
kentaroutakeda
cromwellryan
mongodb
jponch
lemiorhan
soudai
bryan
3n
aleyda
philhawksworth
danielanewman
reverentgeek
sachag
