> As with all ideas, everybody does their own version of it in practice.<p>Yes.<p>> Continuous integration (CI) is confusing.<p>At core, no. Not really. See the 1st paragraph of <a href="https://en.wikipedia.org/wiki/Continuous_integration" rel="nofollow">https://en.wikipedia.org/wiki/Continuous_integration</a> :<p>> In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.<p>So the 2 words are defined as follows:<p>Continuous: at least several times a day.<p>Integration: merge changes to master.<p>It's not a tool: it's a practice, a workflow that builds, tests and tools can help you do safely.<p>Some of these "CI Server" tools also support "build and test the branches" which is useful but is not CI. This is a common mistake.<p>See also: <a href="https://trunkbaseddevelopment.com/" rel="nofollow">https://trunkbaseddevelopment.com/</a>
Someone introduces $buzzword.<p>As software is a popularity contest industry driven by hype and career building blogposts, now everyone needs to do $buzzword so that they can play SEO with their resumes. This is a highly competitive market after all and you gotta put food on the table.<p>smug-faced guru enters the scene: "Oh it looks like you're not actually doing proper $buzzword. Shame on you for raising the hand!"<p>Now you're trapped. You either a) do what the guru says or b) remove $buzzword from your resume before you kiss your children goodbye and prepare for your new homeless life.
> "Of course our build takes long, we have over 10,000 lines of code!"<p>Well, my project misses the 10 minute target by a factor of four, but does include tests and have 670kloc of C++. I claim continuous in this context, thanks very much.
I think this really depends on the code base. If I had a website where a change would trigger more than 5 minutes of integrating and testing I would go mad.<p>I'm working with a weather model and it takes around 1 hour to build and test everything: We build against 2 super computers, 3 different compilers, 2 different architectures (CPU, GPU) and single and double precision. Building alone takes 30 minutes (more in some cases). For testing we reserve 1x node with 8 GPUs and 9 CPU cores on one machine and 2x nodes with 1 GPUs in a 30 minutes debug slot.<p>With a pull-request based workflow we are able to push to the master multiple times a day. 40 minutes might be achievable by massively revamping our build mechanism and getting jenkins to store gigabytes in build artifacts for each run. However, I do not think it is worth it, because changes can take multiple days, or in some rare cases months to implement. If people need to wait for an hour for their tests to validate that's not so bad.
This is an okay and mostly correct introduction for anyone who has never heard of CI, but lacks any sort of depth. The author sounds like he just discovered the concept and wants to share it, but lacks practical experience.
I really don't think build time is very important. With a separate CI server it doesn't much matter if takes an hour or <10 minutes for a build to complete, the gain for me is that it's no longer "your" time. It's some other server that's doing the work with a saved state (master).<p>I'll typically just merge into master on GH, let the CI server take it from there and not bother checking the site manually when the build is complete, it's not necessary. Our QA and CI process handles that.<p>I consider it a major advantage (benefits far outweigh risk) that I can typically merge my ticket into master, close my laptop and head home.
Well a major problem in many organisations is perceived sensitivity of source code, and therefore a reluctance to outsource many tasks which rely on access to such.<p>I like to think "we'll get there".
More important than build speed is the confidence that code which passed to build really works.<p>I think one big reason why organizations don't integrate and deploy often is that people are afraid they will break something when they do this. Then you end up pushing this big and scary thing forward and forward. This of course does not take away any of the risks, but at least you need to close your eyes and wish for the best only once a month.
For those using Selenium or something similar, do you have any tips for making test suites fast? Usually I just test the main flows with Selenium, then go more indepth with unit-tests where parts of the application are mocked out - but it's a trade off between accuracy and speed.