Nick Floyd
Here's a book I pretty much keep in hand all the time: Continuous Delivery by Jez Humble and David Farley. Not that it's a really super enjoyable read, but it helps me remember how doing this software thing we do can be awesome for both the dev and user.
This book is primarily focuses on Continuous Delivery and not Continuous Deployment per se, it etches into an architectural area (around pages 347-349) that I feel every software ecosystem should have.
Feature Dark
dark side rule #1: Releasing small, even unfinished bits into production is ok and will actually save you from head aches.
Delivering features into customers hands should be exciting not terrifying - how many of you have placed bets on the success or failure of a gargantuan release? Why do we have humongous deployments that are scary? Being big and scary didn't really work out for the dinosaurs did it and it won't work for your software either. Create a parallel page, work on the model first - do something other than stop to wonder how you're going to eat the elephant (i.e. big things need to be eaten one bite at a time).
dark side rule #2: Putting software into production does not always mean that you are putting it into the hands of your users. Your software should have toggles that turn features (partial or otherwise) on for either some or all users
I believe that developers should be able to release code right to production, bottom line. If you disagree then you either need to get new developers or you need to start trusting the ones you have. I also believe that every commit after going through quality gates should go right to production once it hits master.
Write your code so that if the doomsday scenario of someone elbowing the keyboard won't put your latest UX redesign in front of your customers. Histrionics aside make your software "releasable." Don't expect a magic bullet here either, this will take team maturity and some patterns for everyone to stick to (like the ones @chadmeyer and I created - pushing features dark). Best idea here is to come up with an easy to understand / use patten and make sure that the business is tooled to flip those switches.
dark side rule #3: Let your business worry about releasing the software to the customers and let your developers worry about writing and deploying said software
See - cd vs. cd. Look @ your keyboard, go ahead I'll wait......
If the symbols <,>,{,},# are worn then you are a developer. Do what you're good at - write and deploy code.
If the # key or the letters a,t,t,n,. are worn then you know who you are. Go put the software developed into the hands and minds of the customers
dark side rule #4: Your features might not always fit into or be able to be feature dark
You just won't. There will be organizational challenges, changes, events and technical roadblocks that will take time to get past. The goal here is to incrementally get there. Be pragmatic.
dark side rule #5: Ruled by fear your competitors are... deploying software all the time you will be...
Note: The dark side rules are my own creations and are only based on my experience with what works and does not work while I have been in dev shops trying to achieve CD, so take them with a grain of salt to season your own rules.