[rubiquity]

Thanks for the article. I apologize in advance if this is a hijack, but I've really been trying to understand the craze of CI and feel this is a good place to hopefully get answers.

CI is something I have a constant struggle with. I primarily work in small teams and I tend to work with other developers that are diligent about running tests and know that "if the tests aren't green when I merge master into my topic branch, I don't push to master."

When I did work on a larger team, maybe CI was useful for the other programmers that weren't as diligent. Though, the CI box eventually got quite slow and you didn't get feedback until 15 minutes later (this was Jenkins) versus 2-3 minutes locally.

Unless I'm missing something, I guess when you distill CI down to what it does you get:

- Runs your test suite

- Lets you know if a failure happens

That's not a ton of value in my eyes, which is why I assume all of these hosted CI solutions are now also doing CD upon successful builds. You could also get CD without CI by using something like git hooks that kick off deploy scripts after certain events.

GitHub showing the status of your CI on the PR screen is cool, but while I do use GitHub, I mostly use GitHub as a code repository. The most I do in the web UI is clone repos and open pull requests. If you merge a branch into master that correlates to an open PR, GitHub automatically closes the PR for you.

I know we're in the era of "Automate ALL the things!" and I'm good about that, but typing `rake|make|etc` into my console isn't a huge pain point in my life right now. Is CI a luxury we've been brainwashed to love by the programming hegemony?

Someone please let me know what I'm missing.

[sjtgraham]

Essentially, no one but you cares that "it's green on my box". Your clone is not the "source of truth".

Also not everyone runs tests before pushing, shocking I know! CI SCM integration makes it immediately clear if a branch can be safely merged. This is such a win for open source projects too. Often I'll get a PR, after seeing the diff and the green build I know I can safely merge. Compare this with adding the contributor's fork as a remote, fetching their changes, running the test suite, merging, pushing. I know which one I prefer.

I'm even more excited about CD, there should be a process for deploying to production and I'm not talking about `git push heroku master`. Code deployed to production should be code reviewed and built by CI before it is automatically deployed. IMO this significantly reduces the probability of deploying bad code.

[novum]

CI means knowing that your product is always in a releasable state. Green tests is only one small piece of that.

I have an iOS app or two that I work on independently, as side projects. Even though I am the sole developer on these projects, CI saves me dozens or hundreds of hours of time. My CI script[0] downloads provisioning profiles from Apple's Developer Center, installs them, runs my tests, builds my app, archives the resulting IPA and .dSYM.zip to Amazon S3, uploads the build to Testflight, notifies my testers, then sends my iOS devices a push notification with an ultimate success or failure message.

And it does all of this every day at 4am, while I'm sleeping, and I don't have to think about it.

How much longer would all of this take if I were doing it manually each time? Time is the only infinitely valuable scarce resource. I don't want to spend time mucking with codesigning and provisioning profiles; I want to spend more time coding.

[0] I've open-sourced my iOS build script! https://github.com/splinesoft/SSBuild

[rubiquity]

If this is all happening at a set time every day, couldn't it just be a cron job? You do have the script created already, CI is just running it for you.

[novum]

Sure it could be a cron job, but using Jenkins adds some conveniences: a nice UI to browse projects, plus it archives the output of every historical build, locally-archived build artifacts, lots of extensibility with plugins, and so on.

[emsy]

Plus: Once you already got everything up and running you can take it a step further and deploy from the CI Server. In my previous job, the Ops Team loved it when I told them how to deploy from the CI instead of going to the "Release Developer" (Which was loathed by the Ops, because she was not the friendliest person :D)

[eddieroger]

It's worth adding that it does those things based on the output of previous jobs. Also, if you have many of these setups in parallel, it can create good dashboards and give you one nice (and free) GUI to take in the state of your build empire.

[jipiboily]

You also are running your tests in a different environment (diff machine) which could catch some bugs IMHO. In addition to that, having the CI server deploying for you also means you can have a very limited part of your team that have actual production rights.

I never had any good experience with Jenkins, Hudson before that or CruiseControl.net (yes, I automated .Net deployment with that, years ago!). This is why I prefer hosted CI that can scale and won't struggle under the load of a few builds. Circle CI in addition will run your specs in parallel. It is very unlikely that you can be faster than them, I think?

For GitHub PRs' status, I think it is useful when you do code review and just get from one PR to the other and you can see it's status quickly, it's a nice to have, but we were able to move fast before that feature dropped a couple of years ago.

It might be a matter of taste, but waiting for the whole suite to run sometime seems like a waste of time, I am most of the time running only the specs that I think could break, and I rarely see red builds on Circle CI.

My 2 cents :)

[rubiquity]

Yeah, I don't run the entire suite either until the merge just before master. While I'm working on a branch I'm only running specific tests.

Having it build and run on a different machine could be valuable for certain applications.

[benjiweber]

CI != CI Servers.

CI is about continually integrating your changes with the rest of the team, and ideally it's also continuous deployment (integrating with production environment continually). The reasons for integrating regularly is to tighten the feedback loop and minimise the integration pain by doing it in frequent, small steps.

It's perfectly possible to do continuous integration without a CI server, particularly when you're also doing continuous deployment.

It's also easy to do the opposite of continuous integration using a CI server. I have seen a lot of people using a CI server to test branches in version control. They have the continuous part but not the integration part.

[rubiquity]

Good to know. So I'm actually practicing CI the way that I work, I'm just not paying some company monthly fees for a CI server. So the difference between CI the practice and "CI wink wink" is $$$.

[xorcist]

Monthly fees? I don't know where you get that from. The state of the art CI tool, Jenkins, is actually free software.

What there is to a complete CI process depends on what your release process is, apart from the build process. There may be code signings, integration with external services etc. These are steps that are not part of the individual developers build process.

The letter I in CI stands for integration. Two checkins might very well look good on their own, but cause havoc with other systems.

[jipiboily]

My 2 cents here, but I think hosting fees will be higher with Jenkins than small CI plans...there are free offerings and even the paid one starts with pretty cheap prices that makes it hard for me to justify even an hour of work configuring a server for that. That said, I know this is not how everyone is thinking.

[aytekin]

Just looked up what kinds of things we do on our CI & CD:

- Run unit and casperjs/selenium UI tests

- Minimize and optimize JS and CSS files if necessary

- Add revision numbers to prevent caching on highly cached files

- Processing less files

- Closure compiler

- Grunt

- CDN cache clears or uploads

- Translation locale strings updates

- Deploying on servers

Tens of tasks/tests done in parallel and finished in 45 seconds.

The most important thing is by automating things, you are dramatically reducing possibility of making mistakes or forgetting something.

[rubiquity]

> - Run unit and casperjs/selenium UI tests

Of all of the steps you listed, this is the only step that actually pertains to CI. The rest are all part of deployment so they would fall under CD.

[aytekin]

Don't agree. Except unit tests, the automated testing should be done on the very final version of the app/site/software, so that you can also catch integration/optimization related problems.

[a-saleh]

It ... depends?

If your rake|make tests last few minutes, you probably can do without CI just fine. I am working Q/A, and each night we run install tests on latest repo, i.e. provision a clean machine, run the install script, check all the daemons are running, run sanity check. This can take ~hour. No dev will take an hour to check if he didn't mess up instalability of the system :) For CI server it is not a problem.

[ZeroGravitas]

Something not mentioned yet is running your tests in the same environment as they'll be deployed. If people dev on Mac OS X it's good to run your tests on the dexact deploy target.

For code that'll be distributed widely, e.g. an open source library, that might mean a test matrix of different language versions, different DBs, and so on.

[fredsters_s]

"brainwashed to love by the programming hegemony" I don't know what this means but I think I love you.