The term Continuous integration originated with the extreme programming development process.It is a practice that is particularly useful for medium to large scale development projects. The essence of it lies in the simple practice of everyone on the team integrating frequently, usually daily, against a controlled source code repository. I have been in software development for quite some time and based on experience, i have learned a common story of software projects: integration is a long and unpredictable process. What people find out as they try CI is that it's much easier than it sounds, and that it makes a huge difference to development. Although Continuous Integration is a practice that requires no particular tooling to deploy,it is useful to use a Continuous Integration server. The best known such server is CruiseControl, an open source tool originally built by several people at ThoughtWorks and now maintained by a wide community. Since then several other CI servers have appeared, both open source and commercial - including Cruise from ThoughtWorks Studios.

Thanks for the write-up. Can you describe how you practice CI, why you started, and the benefits and challenges compared to what you were doing before?

Seun: Thanks for the write-up. Can you describe how you practice CI, why you started, and the benefits and challenges compared to what you were doing before?

@seun, Here is a brief summary of the answer to your question(s):

1. Benefits of CI:
On the whole I think the greatest and most wide ranging benefit of Continuous Integration is reduced risk. The trouble with deferred integration is that it's very hard to predict how long it will take to do, and worse it's very hard to see how far you are through the process. The result is that you are putting yourself into a complete blind spot. Also if you have continuous integration, it removes one of the biggest barriers to frequent deployment. Frequent deployment is valuable because it allows your users to get new features more rapidly, to give more rapid feedback on those features. There is a much greater sense of visibility, because problems are detected faster. Since there is less time between introducing a fault and discovering you have it.

2. Description of how to do CI:
There's no fixed recipe here - much depends on the nature of your setup and team. But here are a few things that we've learned to get things going.

One of the first steps is to get the build automated. Get everything you need into source control get it so that you can build the whole system with a single command. For many projects this is not a minor undertaking - yet it's essential for any of the other things to work. Initially you may only do build occasionally on demand, or just do an automated nightly build. While these aren't continuous integration an automated nightly build is a fine step on the way.
Introduce some automated testing into your build. Try to identify the major areas where things go wrong and get automated tests to expose those failures. Particularly on an existing project it's hard to get a really good suite of tests going rapidly - it takes time to build tests up. You have to start somewhere though.
If you are starting a new project, begin with Continuous Integration from the beginning. Keep an eye on build times and take action as soon as you start going slower than the ten minute rule. By acting quickly you'll make the necessary restructurings before the code base gets so big that it becomes a major pain.

the paraphernalia of modern s/w dev is a field of study on it's own. CI is one d aspects a distributed workforce has to tackle. Is Cruise d same as cruisecontrol? I think there's anoda alternatve competing implementation. Theyre very popular tools in d java world. Java and Its beehive of tools. Ant - build tool . Me na command line. Maven - build tool+ . Maven fans could lynch u for calling their lollypop just a build tool. Junit - unit testing. Nice sounding name "unit Testing" . Httpunit (web versions). MockObjects - anoda tool. Subversion- version control. Alternatives (Git, mercurial, bazaar, bitkeeper, perforce) jperf (or is it jprofiler) - profiling tools. Obfuscators - progaurd.. Enough things to keep learners busy after leaning how to code. And this after understandg d science based foundations of cs , which on its own is anoda vast field. Then when one is gettg settled and familiar anoda new industry changing tool hits d scene. Or d language gets obsolete and programmer has to update to stay relevant

is this not just a name given to a normal developer's routine? write, test and commit.
are you telling me that during the lifecycle of developing a software that you stick to one development pattern?
believe me, I do understand the basic ideologies of these development patterns but I just use it the way it suits me not the other way round.
besides, real programmers ship, checking if every line of code I write adheres to a certain pattern is just redundant

lordZOUGA: is this not just a name given to a normal developer's routine? write, test and commit.
are you telling me that during the lifecycle of developing a software that you stick to one development pattern?
believe me, I do understand the basic ideologies of these development patterns but I just use it the way it suits me not the other way round.
besides, real programmers ship, checking if every line of code I write adheres to a certain pattern is just redundant

a man after my own heart

lordZOUGA: is this not just a name given to a normal developer's routine? write, test and commit.
are you telling me that during the lifecycle of developing a software that you stick to one development pattern?
believe me, I do understand the basic ideologies of these development patterns but I just use it the way it suits me not the other way round.
besides, real programmers ship, checking if every line of code I write adheres to a certain pattern is just redundant

I shared this same feelings,until I had to work with a team of developers that were miles a part.And the common theme was it's working on my machine and it's not working on yours,this was as a result in fairly different development enviroments,was my module tested against their most recent comits etc.With CI the automated tests and builds you get to know as soon as you commit.Again there is no best to do anything but what works for you.

lordZOUGA: is this not just a name given to a normal developer's routine? write, test and commit.

NO! What you are really referring to is Test Driven Development(TDD). Loosely speaking, CI is more useful to large codebases.

This is an oversimplified explanation of CI.

Fork a repository -> hack on it -> test -> refactor -> test -> commit.

You do the above for a while and then you are ready to push your bug fixes/new feature to 'origin:master'. origin:master is the repo you forked in the first place. So you push your commits to origin:master(like a pull request on Github) and that is when CI comes in. Your pull request should trigger a build process on another server. This process runs your tests, builds the projects and does some other shenanigans. If nothing fails, then we are good to merge your work into origin:master.

I hope I explained this properly but I can go into more details if you want me to. Not easy explaining a tricky concept like this from an iPad. One main thing you need to note here is AUTOMATION. I wouldn't necessary call it CI if it's not automated.

To get a glimpse of the above, take a look at projects like Brackets and maybe Bootstrap.

lordZOUGA: besides, real programmers ship, checking if every line of code I write adheres to a certain pattern is just redundant

Something tells me that was a joke. You can't mean that. If you can do this cheaply, why not? By the way CI is not about "checking for a certain pattern", it's there to help you prevent integration hell.

===========================================

@harryobas and @Seun Personally, I find a combination of Github and Travis CI a breeze to setup and enjoy. You setup a hook to trigger a build process for every pull request. You only merge requests the pass the build. Very simple. Travis CI is free and you can also use other solutions like Jenkins.

I understand now. Pattern is not process :-). So I have no gripe with Ci.

Currently using Jenkins CI server running on cloudbees cloud hossting.

From what i understand, when you commit code to your repository, like Fayimora said, it triggers build process and runs your project tes, compiles it etc, if it fails, it will send email to all developers on the team that the commit no: ## made on so so date and time, failed and it will send you the stack trace of the failure too.

My opinion is that is very useful for teams especially when they are not at same location and then for large projects.