Explain continuous integration like I'm five

Imagine you are drawing (programming an app). Every so often you with your father (CI tools) to check if your drawing is ok (passed the test) or not (some test failed). If your drawing is cool and your father approve it then he put it in the fridge (deploy to production) so your mother (users) can see it (use your app).

If your father don't approve your drawing then you need to go back and draw it again (fix bugs).

Now imagine you can do this all the time without stopping, what your father put in the fridge is a copy of your real drawing (a clone of your repository) and you can then continue drawing (sending pull requests) and sending more copies to the fridge, that way your mother will always see the last better version (release) of your drawing.

Continuous Integration (known also as CI), is basically linking your code with a repository (a place to save code), and hire a person, and tell him this:

Whenever I check-in code (a.k.a commit) to this $folder, I want you to build (compile the code) with these $settings and run 100 tests located in this $tests project, after you finish, tell me the $build status and the $tests status.

Some people will be capable of publishing your code, some will upload mobile app package to the store, so you'd tell the new hired person:
And if the build was successful, and the tests passed, I want you to take the package from this $folder and upload to my virtual machine, you can use these conditionals to do so $username/ $password.

Except for hiring a person, it's automated for you, there are companies provide CI services such as Microsoft, they have Visual Studio Team Services (Which I use with my team).

$ means variable, configurable.

Alright, I'll have a go. Continuous Integration for five-year-olds:

Let's say you want to make the Perfect Chocolate Cake. You have a chocolate cake recipe, but it's not perfect and needs some work.

Trying to make the recipe perfect in one single go is guaranteed to not be perfect, and might even make the recipe worse! A better way would be to:

1. Bake the recipe you've got
2. Try the cake
3. If it's not perfect, think about what can be made better
4. Adjust the recipe
5. Bake the new recipe and continue from step 2

This is going to take a long time! To make sure that you can spend more time eating cake and thinking about the recipe, you have a team of chefs (your build server) who will bake any cake recipe you give them. If the cake catches fire while baking (fails compilation) or is inedible (fails a unit test), they'll tell you.

Now, let's say you've got a few different changes you want to make. You want to:

• Add strawberries to the top
• Add melted chocolate in the middle
• Reduce the amount of sugar

Instead of making all of these changes at once to your main recipe, you make three copies of it (branches), each with just one of the changes above. The chefs go and bake you three new cakes!

The new strawberries were great! The layer of melted chocolate was a winner! But the one with less sugar didn't taste as good as the old one.

So you add (merge) the strawberries and melted chocolate layer into your main recipe, but leave the sugar as it was. The chefs bake your new main recipe and it's amazing! Still not quite perfect, but definitely better. Congratulations! You've integrated two changes!

But where's the "Continuous" part? Well, imagine you are doing this with a team - your brother and sister are helping and making their own changes to the recipe. You're all making new changes and experiments at the same time - this could be chaos! To make sure you all don't lose track of the current Best Known Chocolate Cake, you all agree to only make agreed good changes to the main recipe.

And, to make sure everyone can continue to contribute and experiment freely, you also make another copy called "testing", where everyone can put their proposed changes to see if they are good or not, and importantly, you can see how the changes affect each other. When a change is agreed to be good, it gets added to the main recipe.

This all happens on a rolling, "continuous" basis so that good changes can be added quickly, bad changes are stopped early, and the main recipe is always the best it can be.

Bonus! Continuous Delivery for five-year-olds:

When the chefs see that you've made changes to the main recipe, they bake lots of them to put on the shelves of your amazingly successful cake shop!

You have a giant pile of Legos and you want to be a super cool machine.

You and three friends all decide to build different parts of the machine. At first you build your part out completely, and then you try to fit them all together.

Your machine is fragile, the pieces don't fit right and nothing works.

So you try again, this time, you build much smaller parts and fit them together sooner. They sometimes don't fit, but you can make changes really quickly so they fit and do what you want them to do. Soon you see a machine built out that does what you want and it works together.

Continuous Integration is like the second way. Smaller things get built and then are added back to the bigger thing. If something isn't working, it's easier to fix. Developers can build an end product that works well together faster than trying to build features separately.

Automate everything in your development process, besides coding.

For example, run a server that gets a message when you push new changes to Github. Then this server checks out the new version and runs the tests and if they work, it copies your new version to the production system and restarts everything there.

This is the most basic version.

You could also automate the compilation for different platforms and tests on them.

Or deploy to 50% of your users with one version and 50% with another version of your software and wait till one of side cries so you know which was the bad part.

Main point here is, that something runs automatically that you would do after finishing chaning your software.

I can't help but feel like everyone here is way off so far. Lots of talk about automation, but no talk about actually integrating code frequently. The tests and automation merely support and make it easy to integrate our code daily (or more!).

It's pretty succinctly described at thoughtworks.com/continuous-integr... -- not much I could add to that. If I were genuinely going to describe it to a five-year-old, it would be more like, "Continuous Integration is awesome -- especially because it gets you ready to do Continuous Deployment, which is even more awesome!" :)

Oh yes, i do:
it's like drawing the eiffel tower in classroom. Each child draws a part of it and regularly makes a copy (using some numeric tool) that it displayed on class dashboard and the teacher tries to make a whole out of them. Any child can propose modifications of any part, it gets displayed, until everyone is satisfied with the result.

websites are made from computer files that contain code. code is just a bunch of instructions that are written in a language that the computer can understand.

for the websites that you visit on the internet, the code instructions are being read by a computer far away, and that computer thinks about the instructions and puts together (the website) and sends the finished website to your computer over the internet wires for you to look at.

there isn't just one copy of the website code, sometimes many different people work on the same website code at the same time. for this we create a special place to keep our code where everyone can share it, sort of like the junk drawer in the kitchen.

the people who write the code write it on their own computers, usually laptop computers that they can take anywhere with them. so that everyone can work on the code wherever they are, they each make a special copy of the (junk drawer) on their laptops. when they are done making changes to the code and want everyone else to see their changes, the push their changes back to the (junk drawer).

with more than one person making changes at the same time, you might think that my changes and your changes and her changes and his changes might not work well together. if we all push our changes together and then update the code on the website computer (without checking what happened when we put all those changes together), things might look all messed up and broken.

that’s why we make tests for our code - tests are another set of instructions saying what we want the code to do. if it was the junk drawer, my test might say ‘when i push the button on the flashlight, i expect the flashlight to produce a bright light’ if this test passes, we know this code is good (or at least does what we wanted it to do)

this is important because someone else’s new code might say ‘take the batteries out of the flashlight’ oops - their code did something that broke my code! good thing we wrote those tests. (we did write those tests, didn’t we?)

we need another special computer that is constantly watching for these changes and running these tests every time someone makes a change. that way, we know immediately if the code we wrote broke the code that someone else wrote.

if all the tests pass after someone makes a change, we should be good to push that new version of the website to the website computer so that you see the updates that we made.

Imagine you're having an assignment for school with many exercises, where each exercise is dependent on the previous ones. So, if you haven't studied the material well and mess up an exercise it's highly possible that you'll mess up the next ones.

Now imagine that you have a machine that each time you complete an assignment, it checks and verifies that this exercise is correct, so that you can proceed to the next ones without being afraid that you've done a mistake in the previous ones. Welcome to Continuous Integration.

In CI, your code is deployed to the server with every change. That is, assuming your code does not break the tests that are written today.

This might sound natural at first when you consider a decade ago it was common to have someone live editing PHP scripts on a production server. Now we keep great version control of software. It's also been common to release new software updates in big batches monthly, quarterly, annually, or worse. Today, the problem with this approach is subtle bugs are discovered very late in the game, and as a rule of thumb, the bigger the set of changes is, the more likely bugs will be introduced.

CI is a reaction to these trends. We'd like to have the stability of running (and passing) our tests first before hitting prod, but we'd also like to not have release cycles be long. This allows us as developers with CI to roll out bug fixes and new features to production on a continuous basis.

You just don't do CI if you are five years old.
It's a +18 thing adults do, even knowing that doing so may hurt them.