From Wikipedia: Continuous Integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. Continuous Integration involves integrating early and often, so as to avoid the pitfalls of "integration hell". The practice aims to reduce rework and thus reduce cost and time.
Continuing reading Wikipedia talks about recommended practices:
- Maintain a code repository
- Automate the build
- Make a build self-testing
- Everyone commits to baseline every day, and every day is built.
- Find integration problems fast.
- Test in a clone production environment.
- Easy to get latest deliverables.
- Everyone can see the results of last built and correct quickly.
Continuing, you can read the advantages of CI and the disadvantages (only a few). If you look closely to disadvantages talks about required hardware and about initial time setup.
What if you had a single file (debian file) that you double click and whalaa!!! Your Continuous Integration server ready to work. Then you didn't need spending time for configuring or searching over internet, tools or plugins for making your system completely workable.
The best guy for talking about CI is John Ferguson Smart from Wakaleo. His main purpose is helping people building software better, and in his presentations (I recommend you go to their workshops and public presentations), you can learn which tools are better for you.
So we have the knowledge (thanks of John), we have the software (thanks to open source community), only an installable is required that mount into a server all CI architecture (applications, plugins), configure them (system environment), and connects between them. And that's where I come to play. I am developing a debian file that will install all required applications, configure them and interconnect.
In present post I am giving birth to Milestone 1 of that file.
This first Milestone installs next components:
- Apache Maven 3.0.2
- Apache Tomcat 7.0.6
- Nexus Open Source 188.8.131.52
- Jenkins 1.396
- Sonar 2.5
- Template Repository 0.1
Before installing all packages you should have set correctly JAVA_HOME environment variable.
And I suppose you are wondering, exactly what installs and how is configured. Next lines explain that:
Apache Maven 3.0.2 installed in /usr/share/apache-maven-3.0.2 with settings.xml file configured for downloading plugins from installed Nexus, maven local repository to /opt/maven/repository and global environment variables created. Maven environment variables are exported into /etc/profile file.
Apache Tomcat 7.0.6 Tomcat 7 installed in /usr/share/apache-tomcat-7.0.6 but with catalina.sh file modified for adding Sonar options to CATALINA_OPTS, and JENKINS_HOME and PLEXUS_NEXUS_WORK pointing to their working directories.
Nexus Open Source 184.108.40.206 server installed to
:8080/nexus with predefined repositories. Internal repository is set to /opt/nexus.
Jenkins 1.396 continuous integration server installed to :8080/jenkins. Jenkins home is /opt/jenkins. It is already configured for working with installed Maven and Sonar. Also comes with next plugins:
First Known Issue: don't know why but my postinst file does not read my JAVA_HOME so does not configure Jenkins JAVA_HOME correctly. I am sure the problem is in my linux installation so it is possible that in your computer works perfectly, if not, goes to /opt/jenkins/config.xml and inside
tag just under JDK 6 tag write your JDK path (same of JAVA_HOME). Also can be set using Jenkins configuration menu. I suspect that with root user variable JAVA_HOME defined into /etc/profiles is not available.
Sonar 2.5 is installed into Tomcat in :8080/sonar, its configuration directory is /opt/sonar and is is already configured for working with Nexus.
Template Repository 0.1 this is a module I have created, and is installed in :8080/template-repository. What you find here is PMD and Checkstyle files used by Sonar for scanning projects, so developers can download them and use the same Sonar configuration into the IDE plugin. Also a settings.xml configured with Nexus repository, so developers should only download and copy it to maven configuration directory.
Maven Parent POM with distributuionManagement addressing to Nexus server, repositories also addressed to Nexus. There are also three "must on" dependencies for TDD (Hamcrest, Mockito and JUnit), a profile with name metrics (can be activated with -Pmetrics) which contains metrics for PMD, Cobertura, Findbugs and Checkstyle. Another profile called source-javadoc which creates a jar with attached source files, and another one with javadocs. Also three plugins are installed: maven-compile, maven-deploy (configured for uploading to Nexus) and versions-maven. Although is defined as parent POM, this POM is used as inheritance and aggregation.
Template POM that is configured for being used with previous parent POM. I have written down some SCM configurations, only uncomment the line that configures your SCM. And finally defines maven-release plugin.
Second Known Issue: Sometimes don't know why but Tomcat does not start, it shows a message that Nexus are being deployed and stays there forever. I have noticed that only happens the first time you start Tomcat. If this happens simply stop tomcat (Ctrl+C) and restart and the second time works perfect.
The project have no name, and for now I don't have any idea, so for now the package is called cis (Continuum Integration System), I wish in future versions I can find a better name, if anyone have any suggestion it would be welcomed.
Also I am open to receive suggestions of which plugins should be added, or components that a CI system should have.
Final note, for now, Tomcat is not started as a daemon, but I have an init.d file prepared. In final release this file will be also copied into /etc/init.d, but for now I prefer a manual start using catalina.sh run command.
This is a Milestone 1, it is possible that for Milestone 2, you should remove previous installation. Install it for see how it works and whether it can be helpful in your company
Download Milestone 1 from GITHub.
Milestone 2 should contain next features:
- Eclipse Update Site with useful plugins. Because all developers should use the same plugins, System Manager can upload there plugins and make them public into project. All developers should only defined this updatesite into their Eclipse.
- Fix possible bugs.
- Add features asked by community.
- Add to taskbar direct links to installed components.
- Upgrade to last components version.