Can you explain Continuous Integration like I'm five ?
For further actions, you may consider blocking this person and/or reporting abuse
Can you explain Continuous Integration like I'm five ?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (13)
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.
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.
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.
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!).
Right. Integration is about merging code into a mainline branch. Automation and continuous testing make the integration easier.
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.
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!" :)
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.
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.
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.
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.