Continuous Integration and Deployment - But WHY?

I know that title probably got you here to start your rants on why it is amazing and best practices and... I get it. I know. Trust me, I am a HUGE fan of automation. If I have to do something more than two times, I want to spend more time to automate it. Let's get to the topic...

Continuous Integration vs Continuous Deployment

Several people have asked me what's the difference between CI and CD? That is easy.

Continuous Integrations merges into the master branch verifying the build process (automated tests and builds)

Continuous Deployment goes a step further and actually deploys the latest code to the environment

That's really the difference.  In some cases, you may want CI and in some you may want CD.  I generally use CD for Dev/QA and CI for UAT. I'm still not 100% on CI for production... just a trust issue based on past experience. However, if you want to improve your CD process, implement it on production, you'll be quick to iron out any issues. :-)

Ok, so now you know the difference between them... what's the advantage of it? Why use it?

Why do I care about CI/CD?

Truth is, you may not. Are you a blogger who runs a self-hosted WordPress site (or not self-hosted like Wordpress.com), if so you probably don't care. Are you updating templates and data models for your CMS, or are you building Web/Mobile Apps and want to see them before they hit production? Then you should care.  There are a lot of process out there that are labeled the best practice for things.

Local -> Dev -> QA -> UAT -> Staging A -> Staging B -> Production B -> Production A

That is A LOT of environments to maintain and to handle deployments to and from. Do you need all of that? Maybe.  What if you are doing A/B testing on a production environment and need a staging A/B environment to make sure you won't break 50% of your customers? In most cases, we simply don't need all of that. Local -> Dev -> QA -> Prod... or Local -> QA -> Prod.  However, there are little nuances of moving code between environments.

Welcome to CI Tools

There are a lot of them. I referenced this earlier (Periodic Table of DevOps) and the CI area is filled with TeamCity, Jenkins, Codeship, etc... Those tools allow you to migrate, integrate, and most of the CI tools allow you to do deployment also. But imagine a world, where you check-in code, automated tests are run, build is completed, and is immediately on an environment for testing/validation?  YAY! Even better though, the tests are run and fail, and you are notified that they failed with helpful messages, and the build is NOT deployed because of that failed test.

Anyway, let me get to my point. CI tools are great, but if your daughter asks you to setup a blog for her, you do not need to over-engineer it and create multiple environments with deployment strategy and fail-over clusters for db reliability. You simply go, "Here's wordpress.com, create an account and share your thoughts.".

Developers so often jump to over-engineering problems because they feel it makes things more stable, more reliable, more scalable... insert your favorite buzzword... But aren't more moving pieces contributing to more fragility? If I develop right on production, I could potentially take down the site with no recourse except fix it immediately. Don't develop on production! But don't create such a complicated infrastructure that prevents you from developing an amazing product and by the time you figure out how to release it through your Rube Goldberg machine of deployment, someone else already beat you to market.

There are a multitude of tools that help you be a more efficient developer. It is up to you to know when and more importantly when NOT to use them. There is not always a blueprint for the answer of your project. Sometimes you need to change things, and approach it differently for your scenario.