Continuous Integration (CI) misconception

In some online resources the term Continuous Integration (CI) is always used in the broadest sense to mean that on some schedule or event the outputs of every ongoing project or separate teams are obtained, put together somehow, and then a test system is updated so that various tests can be invoked. No wonder some test and management professionals are wary of the concept.

The problem here is the “other” usage. More correctly CI can even be applied to one team on one project. One distinguishing feature of CI is that there are multiple developers*. Thus, as these developers complete various tasks and commit or push to a shared repository, a build and deploy process is run to create testable systems.

The term “integration” in CI is applicable to more inclusive senses, or a fuzzy continuum, from one project and one team to combinations of these. Thus, some processes are CI to a certain degree, or worse very CI anti-pattern to a certain degree.

In the modern CI best practices, CI is done via various build and deployment servers that automate some or all of the pipeline. In the past at some companies, the designated build person was doing manual Continuous Integration.

Sure, in CI there will be episodes of actual integration with other current projects, teams, or externally generated artifacts. If this is automated, then we have full CI.

* Even a single developer who uses various branching strategies on one code base may use CI practices.

Links

• Continuous integration
• CI Refcardz: Continuous Integration

Jenkins CI Server is great

Finally got a Jenkins server installed. Had a host of system issues, like communicating to our source code repo.

Jenkins is a joy to use. Well, it is not perfect, what is? Like, I need to pass the user’s name that invoked a build via Jenkins to the target DOS script (yea, Windows) that eventually invokes the legacy Ant scripts. A quick Google search shows that this is asked in various ways, but no answers. For example, here or here. Hmmmm.

Anyway, now comes a trial use, to see if it is what we really need and can we manage it to do what we will want. With 400 plugins, I don’t see how it could lack. Plus, I’m sure I can use the Groovy plugin to cobble something up. Jenkins even includes a Groovy Console. Finally, there is a road map for possible migration of legacy Ant scripts to Gradle using the Gradle Plugin.

I take back my past snarky comment. Jenkins is not just a pretty face on Cron.

Off Topic
Was watching the Easyb intro video. BDD is interesting. Definitely “should” is a better then “test”. With so many great tools why are products still bug ridden?

Enterprise Level CI Server?
I was told that QuickBuild is better for corporate use.

Wikis and the home link
BTW, is there some Wiki law that says a wiki shall never ever have a link to the parent project? If you get tossed into a wiki by following a link, invariably you will click in agony at links that should go to the real home. Instead, you have to edit the URL in the address bar. Since I never curse, I can’t write “wtf”.

More stuff

1. Jenkins home page

QuickBuild

2. Continuous integration Not a very good Wikipedia article
3. Continuous Integration Much better
4. Continuous Integration in Agile Software Development
5. Hooking into the Jenkins(Hudson) API
6. Five Cool Things You Can Do With Groovy Scripts
7. Parameterized Builds in Jenkins – choosing subversion folders
8. Groovy Console
9. Groovy plugin
10. Switching to Jenkins–Download and Install Artifact Script for Tester
11. Gradle Plugin

Hudson/Jenkins CI Server, can’t edit a job?

I was looking at a possible use of a Continuous Integration Server to quickly set up a build process.

Downloaded the Jenkins war file, put into Tomcat and defined a simple Job that invoked an Ant file to echo “Hello World!”. Cool, that was easy. But, then I wanted to expand that job to do more. Could not find a modify or edit capability. Huh? What’s up with that?

I searched and found very little. There was even some mention of using SED to edit the Job configuration XML, yeeech! Edit using a text tool for a tree-based data structure?

Anyway, not impressed. Of course, this was a quick tryout. Or maybe Linux people are so perfect they never have to edit their work. 🙂

Is Jenkins/Hudson just a pretty face on *nix utilities?

I looked at a few other CI Servers. So far Pulse and Team City look interesting, but they are not free.

Updates
Mar 2, 2012: Used one of the latest Jenkins version. Much much better! Though I’m having issues getting Active Directory authentication going. Can log in ok, but then it uses the wrong user “name” that our PCs must use. You know how LDAP has all this distinguished this or that.

Links

1. Jenkins
2. Active Directory Plugin