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.  

Trello -- Get Your Scrum On

For more than a year I was on the receiving end of 'why is your scrumboard not electronic' line of questioning from my team, my leadership, my customers and pretty much anyone else who had an opinion on the matter.

Our scrum room looked like this:

Despite making my living utilizing tech, it proved difficult to defend the 'old school' post-its and whiteboards.  There were a few things that compelled me to keep my distance from Agile tool sets.  For those of you that utilize more sophisticated tool chains, good on ya and I'm not implying there is anything wrong with them.

Licensing costs, risk of loss of proprietary information in cloud-based systems, feature sets that I trust we'd never use (e.g. burn-down charts and metrics) and most importantly I personally felt the  satisfaction of disclosing your task completion and physically moving a task from 'in progress' to 'complete' with a sense of accomplishment.  My resistance was reinforced when participating in sprints led by other scrum masters that used 'MS Excel' (I know, wrong tool) and the tone of the meeting became more a status meeting than a scrum.

I yearned for a scrum room with a wall-sized electronic smart board; electronic equivalent of post-its and baby, Trello is pretty close to what I wanted.

Free to use, flexible, and pretty much what the doctor ordered.  I invite you to take a look.  I've found myself using it at work, home and play and use it from such mundane tasks as packing luggage items to coordinating my blog backlog.

Take a peak, you'll be glad you did.

http://trello.com