What is CI/CD?

https://www.nytimes.com/2018/01/31/sports/football/quarterback-signals-hut.html

Imagine American football without 'an audible'; you huddle up, you make a decision on the play and you fully commit to executing that play 100% regardless of the new evidence as it presents itself.  It's very likely, regardless of the teams leadership or the talent of the team, you'll end up losing to an equally talented team that is willing to change course on the play if the situation demands it.  That, in part what continuous integration and continuous delivery is meant to address.

Traditionally, software development teams would collaborate with other departments to establish a plan (i.e. features/bugs/refactoring efforts for the next product release), vanish from site to focus on the design and development tasks in isolation only to rejoin the society after completing the development efforts to deliver a new build for testing and feedback.  A team may have a dozen or so activities, many self-contained and independent from one another, but the traditional model would tend not facilitate an internal build for feedback or testing until all development activities had concluded.  This results in an artificial bottleneck by holding up the possibility of testing and feedback efforts until much later than necessary.  

Continuous integration (CI) and continuous delivery/deployment (CD) are intended to remedy that by investing effort in creating an environment that creates autonomously creates builds during the development process that can be utilized by external stakeholders (e.g. testers and other internal customers).  This is often referred to as the CICD pipeline.

Continous Integration

Continuous integration has the goal of automating the process of building and performing automated tests on the latest changes to the code base.  When a developer completes an activity they commit the changes to the code repository, the build system recognizes that a change has been made available and creates a build.  A successful build means little more than 'it compiled' so to gain confidence in the change the build is made available to a testing system which performs a series of automated tests on the build.  If the tests pass, you have a newly available build with a level of confidence in it.

@todo graphic: developers x N => code repository => build system => test framework

Continous Delivery/Deployment (CD)

The CD stands for two independent concepts: continuous delivery and continuous deployment, separate concepts but related by nature.  Typically, continuous delivery is often supported, continuous deployment is considered optional in many circles.

Continuous Delivery

Continuous delivery involves simply making new builds available for use.  Simply copying a successful build, preferably one that passed the automated tests, to a shared location where stakeholders can access them and you've essentially satisfied continuous delivery.  The builds may be acted on, or ignored, the automation means it didn't cost any manual developer time so no resentment in not acting on any particular build.

Continuous Deployment

Continuous deployment takes this step a bit farther by automatically deploying the new build to target systems.  For instance, perhaps you have a sophisticated automated test system that is capable of conducting performance testing.  A new build becomes available, the test system updates to the latest build and executes performance testing on the new build to ensure there is no regression in performance.  This concept could go as far as performing continuous deployment to production servers, although the thought of such a system gives me a shiver.

That's pretty much it, in a nutshell.