Continuous Integration

Theory: 1. Developers need to start on issue from a clean beginning. 2. Avoid Integration Hell, where a developer needs to re-write the whole code. 3. All programmers should start the day by updating the project from the repository. That way, they will all stay up-to-date.

Recommended Practices: 1. Maintaining a Code Repository: a. Using a Version Control System for a Code Repository. b. Every dependant file to do the build should be put in the Repository. c. Code repository is preferred to keep in the testing server. 2. Automate the Build: a. A single command should be able to trigger the Build. b. Use of automatic building tools like Ant, Maven and MSBuild. c. Making the build self-testing. d. Using a dedicated testing server (a preferable replica of the production server) for the build (if possible). 3. Regular commits by the programmers. 4. Test Server monitors the version control system for changes, then automatically runs the build process. 5. Keeping the build fast so that conflicts or bugs can be quickly identified. 6. Using the Testing Server, which is the replica of the production server, is very useful to test the release build before actually deploying to the production server. 7. Regular builds to be submitted to the stakeholders and the testers. 8. Programmers should be able to monitor and see the latest test results.

9. Automatic Deployment.

Advantages: 1. Reduced risk. 2. frequent deployment 3. On fail builds, reverting back to an earlier stable state. 4. Fix and detect problems continuous without last minute troubles. 5. Early warnings, conflicts and fail tests. 6. Constantly available test and release builds. 7. Immediate feedback on the Code and the effect of the code on the whole system. 8. Metrics from the continuous integration functional, quality code, and help develop momentum in a team. Disadvantages: 1. Initial setup requires time and investment. 2. Well-developed test-suite testing advantages. required to achieve automated due to

3. Large-scale re-factoring can be continuously changing code base.

troublesome

4. Hardware costs for the test server can be significant.

Best Practices: 1. Pull and build the whole application in the local machine before committing all the changes and pushing to the test server for a release build. 2. Automated Build should have all the dependencies, tests, third party libraries, Database Schemas and install scripts. 3. Source control should contains all the files necessary for building the project. 4. Higher commit frequency means low time invested in finding a bug, resolving conflicts and low fail builds. 5. One of key points of continuous integration is finding and fixing bugs and conflicts right away. 6. Build should be relatively fast so that bugs can be found out fast and fixed. 7. Every programmer should commit to the central repository everyday.

8. Every commit should build on the Integration Server. 9. Integration Server should be a clone of the Production Server. 10. The Integration should be visible and accessible to all the stakeholder and testers. 11. Automate Deployments

Jenkins
What is Jenkins? Application that monitors executions of repeated jobs, such as building a software project or jobs.

Why use Jenkins? Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity. Monitoring executions of externally run jobs, receive regular emails that capture the output, and notice when it broke. Jenkins keeps those outputs and makes it easy to notice when something is wrong.

Some features of Jenkins: 1. Easy installation and configuration Jenkins uses a friendly web GUI and XML. 2. Support change tracking. 3. Monitoring builds by emails. 4. Automated test reports, summary and even graphs. 5. Distribute build/test loads on different computers. 6. Jenkins can keep track of which build produced which jars, and which build is using which version of jars, and so on. 7. Supports third party plugins.

Installing Jenkins: 1. By default Jenkins is installed in port 8080. 2. In Windows:

a. https://wiki.jenkinsci.org/display/JENKINS/Installing+Jenkins+as+a+Windows +service 3. If you have a servlet container that supports Servlet 2.4/JSP 2.0, such as Glassfish v2, Tomcat 5 (or any later versions), then you can run them as services, and deploy jenkins.war as you would any other war file. 4. Starting Jenkins as a Daemon in Unix: a. https://wiki.jenkinsci.org/display/JENKINS/Installing+Jenkins+as+a+Unix+da emon

Starting Jenkins:
$ java -jar jenkins.war

Jenkins Best Practices: https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Best+Practices