Jenkins Debian packages

1. http://pkg.jenkins-ci.org/debian/

2. Jenkins offers the following features:

   1. Easy installation: Just java -jar jenkins.war, or deploy it in a servlet container. No additional install, no database.
   2. Easy configuration: Jenkins can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There's no need to tweak XML manually anymore, although if you'd like to do so, you can do that, too.
   3. Change set support: Jenkins can generate a list of changes made into the build from Subversion/CVS. This is also done in a fairly efficient fashion, to reduce the load on the repository.
   4. Permanent links: Jenkins gives you clean readable URLs for most of its pages, including some permalinks like "latest build"/"latest successful build", so that they can be easily linked from elsewhere.
   5. RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.
   6. After-the-fact tagging: Builds can be tagged long after builds are completed.
   7. JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.
   8. Distributed builds: Jenkins can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers' desks.
   9. File fingerprinting: Jenkins can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Jenkins, and is ideal for projects to track dependency.
   10. Plugin Support: Jenkins can be extended via 3rd party plugins. You can write plugins to make Jenkins support tools/processes that your team uses.

3. Jenkins Best Practices

   Always secure Jenkins.

   This best practice is around authenticating users and enforcing access control on a Jenkins instance
   In the default configuration, Jenkins does not perform any security checks. This means any person accessing the website can configure Jenkins and jobs, and perform builds. While this configuration is normally acceptable for intranet use and quick setup, it introduces high security risks, like someone accidentally deleting your build jobs, reconfiguring your job to run every minute, kicking off too many builds at the same time, reconfiguring your build instance, etc. 

   Backup Jenkins Home regularly.

   'Nuff said. 

   Use "file fingerprinting" to manage dependencies.

   When you have interdependent projects on Jenkins, it often becomes hard to keep track of which version of this is used by which version of that. Jenkins supports "file fingerprinting" to simplify this, so make best use of it.

   The most reliable builds will be clean builds, which are built fully from Source Code Control.

   To ensure a build can be reproducible, the build must be a clean build, which is built fully from Source Code Control. This practice also implies that all code including third-party jars, build scripts, release notes, etc. must be checked into Source Code Control.

   Integrate tightly with your issue tracking system, like JIRA or bugzilla, to reduce the need for maintaining a Change Log

   The integration helps to track changes as they are made, including build status, what build has been performed for this requirement or defects, and the link to the actual build results and artifacts.

   Integrate tightly with a repository browsing tool like FishEye if you are using Subversion as source code management tool

   Repository browsing provides a quick update on what happens on a Subversion repository. It also provides a graphical diff on what changes have been made from the previous build.

   Always configure your job to generate trend reports and automated testing when running a Java build

   Trends helps project managers and developers quickly visualize current project progress status. Moreover, unit testing is often not enough to provide confidence that the delivered software complies to the desired quality. The more you test the software, the better the delivered software complies to the desired quality.

   Set up Jenkins on the partition that has the most free disk-space

   Jenkins needs some disk space to perform builds and keep archives. All the settings, build logs, artifact archives are stored under the JENKINS_HOME directory. Simply archive this directory to make a back up. Similarly, restoring the data is just replacing the contents of the JENKINS_HOME directory from a back up.

   Archive unused jobs before removing them.

   All unused jobs should be archived so they can be resurrected if the need arises. See Administering Jenkins for ways to do this.

   Setup a different job/project for each maintenance or development branch you create

   One of advantages of using CI tools is to detect problems early in the development lifecycle. Setting up a different job/project for each branch you create will help to maximize the benefit of detecting problems early as part of supporting parallel development efforts and reducing risk.

   Allocate a different port for parallel project builds and avoid scheduling all jobs to start at the same time

   Multiple jobs running at the same time often cause collisions. Try to avoid scheduling all jobs to start at the same time. Allocate a different port for parallel project builds to avoid build collisions.

   Set up email notifications mapping to ALL developers in the project, so that everyone on the team has his pulse on the project's current status.

   Configure each person on the people list with his or her correct email address and what role he or she is currently playing.

   Take steps to ensure failures are reported as soon as possible.

   For example, it may be appropriate to run a limited set of "sniff tests" before the full suite.

   Write jobs for your maintenance tasks, such as cleanup operations to avoid full disk problems.

   Tag, label, or baseline the codebase after the successful build.

   Configure Jenkins bootstrapper to update your working copy prior to running the build goal/target

   In larger systems, make sure all jobs run on slaves. This ensures that the jenkins master can scale to support many more jobs than if it had to process build jobs directly as well.