anchor.diff:  We had everything except for one important piece -  delivering quickly. We were delivering to production every two weeks, which sounds “not so bad,” but was not a business decision. We were unable to deploy any sooner than that. The product manager was exceptionally frustrated that they were unable to do daily ‘continuous deployment’ as the business needed to.   
     
   
  -## Confession: We did not pay attention to the other core principle of continuous delivery, which was to deliver changes reliably
  +## _Confession: We did not pay attention to the other core principle of continuous delivery, which was to deliver changes reliably_
   
   
   The second problem we had, was that when it came time to deliver, the likelihood of key features working was only about 50%. All that monitoring we had in place wasn’t giving us usable feedback. We were forced to rely on manual testing or using a small test group to inform us of any failures. We were unable to move the product forward for public use. 
  
positive.code: 
  
      
  ## Confession: We fulfilled all the practices on a checklist, but we failed on the core principle which is ‘to deliver changes quickly’
  
  Snap CI’s team had very enthusiastic and experienced CD practitioners. The team wanted to do ‘everything CD’. Within six months after we began the product, we had a microservices architecture with nine different components, sophisticated messaging queues, monitoring, an automated infrastructure, and deployment pipelines for all of these different components.  
  
  
negative.code: We learned that users don’t care if your team is practicing continuous delivery or using microservices. These are decisions a team makes to ensure what they build reaches users quickly and reliably. It’s easy to get caught up in the checklists, “doing CI and CD”, trying cool new microservices etc. 
  
  
  > _**Do the important things first that will deliver code quickly and reliably and then evolve and move forward on your journey.**_
  
  
  The second lesson we learned was that CD is a journey. It's an evolution, and you first need to set your goals driven by your business and then make your way there. It is tempting to move to the latest practice or new technology as soon as you hear about it. However I recommend that  in the first few weeks, unless you are 100% sure that that's what you need, don’t make any major architectural decisions. Do the important things first that will deliver code quickly and reliably and then evolve and move forward on your journey.
  