The document provides an overview of version control systems, particularly focusing on Subversion (SVN) and Jenkins for continuous integration. It details the benefits, installation, and best practices for using SVN, as well as the principles and steps necessary to get started with Jenkins. Additionally, it discusses various models and examples of both proprietary and open-source version control and CI tools on the market.

2. Introduction
• University Faculty • Employee - IT
Company
• Batch, Pascal, PERL, • Shell Scripts
Javascript, C++, JAVA
• DUNE2 • Modern Conflict
• I love to visit all the nearby islands of Cebu.

3. • Introduce version control and CI
• Focus only on Subversion and Jenkins
• Discuss about installation and getting started
with these tools.
• Sharing of personal experiences pertaining to
the tools mentioned is also encouraged during
the Q&A.

4. Version Control
• Also known as revision control.
• According to http://www.smashingmagazine.com/ the
most obvious benefit of revision control is
– ability to have an unlimited number of people
working on the same code base, without having to
constantly send files back and forth.

5. Models of Version Control Software
• Local data Model
• Client-Server Model
• Distributed Model

6. Version Control in the Market
• Proprietary
– BitKeeper
– PVCS
– Synergy
– Perforce
– ClearCase
– Visual SourceSafe
– Rational Team Concert

7. Version Control in the Market
• Open Source
– Concurrent Versions System (CVS)
– Subversion (SVN)
– Distributed Concurrent Versions System (DCVS)
– Bazaar
– Mercurial
– Git

8. • Triggered development by CollabNet, Inc in early
2000
• Took 14 months to develop
• Became part of ASF's family of top-level projects
on early 2010.
• Book titled Version Control with Subversion can
be found and/or downloaded at
http://svnbook.red-bean.com/
• Subversion current version is 1.7

10. Subversion repository

11. Repository access URLs
Schema Access method
file:/// Direct repository access (on local disk)
http:// Access via WebDAV protocol to Subversion-aware Apache server
https:// Same as http://, but with SSL encryption
svn:// Access via custom protocol to an svnserve server
svn+ssh:// Same as svn://, but through an SSH tunnel

12. 5 steps to getting started
(Version Control)
1. Download and install
2. Create the repository
3. Set-up authentication
4. Customize (e.g. pre-commit hooks)
5. Perform maintenance like backups

13. Create the repository
• Create the directory
mkdir –p /var/www/svn
• Create the repo
cd /var/www/svn
svnadmin create myrepo
• Access the repo via http
http://143.143.143.143/svn/myrepo

14. Content of subversion.conf
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
<Location /svn>
DAV svn
SVNParentPath /var/www/svn
AuthType Basic
AuthName "Subversion repositories"
AuthUserFile /etc/httpd/svn-users.passwd
Require valid-user
</Location>

15. Structure of SVN Repository
• trunk - directory to hold the “main line” of
development;
• branches - directory to contain branch copies;
• tags - directory to contain tag copies;

16. Customize
• Use of hooks like pre-commit
• The pre-commit hook is run just before a
commit transaction is promoted to a new
revision.
• Useful for freezing a release and/or requiring
for log messages before revisions are
committed to the repository.
• /var/www/svn/myrepo/hooks/pre-commit

17. Backups
• Full backup
svnadmin hotcopy /var/www/svn/myrepo ~/repo-backup
tar cjvhpf repo-backup.bz2 ~/repo-backup
• Incremental
svnadmin dump /var/www/svn/myrepo –r 143:HEAD --
incremental > `date +%s`.dump

18. Subversion Best Practices
1. Use a sane repository layout
2. Commit logical changesets
3. Use the issue-tracker wisely
4. Provide meaningful log message
5. Know when to branch

19. Continuous Integration (CI)
• implements processes of applying
control — pieces of ,
applied .
• a set of software development practices,
behaviors, and principles for automating and
improving how to integrate and certify
software continuously.
• Started around 1999

20. • to deliver stable, high-quality code
consistently and quickly;
• detect and fix problems early;
• deliver quality software;
• reduce time to market of the finish product;

22. Principles
• Maintain a Single Source Repository
• Automate the Build
• Make Your Build Self-Testing
• Everyone Commits To the Mainline Every Day
• Every Commit Should Build the Mainline on an
Integration Machine
• Keep the Build Fast
• Test in a Clone of the Production Environment
• Make it Easy for Anyone to Get the Latest Executable
• Everyone can see what's happening
• Automate Deployment

23. CI in the Market
• Proprietary
– Build Forge
– AnthillPro
– BuildMaster
– TeamCity

24. CI in the Market
• OpenSource
– CruiseControl
– Jenkins/Hudson

25. 4 steps to getting started (Jenkins)
1. Download and install
2. Create and configure the project/job
3. Run your first build
4. Customize

26. http://jenkins-ci.org/

27. Configure Jenkins

28. New job/project

31. Plug-ins
• Over 400 plug-ins
• Source code management (e.g. Git, Mercurial)
• Artifact uploaders (e.g. Tomcat, JBOSS,
Websphere)
• Build Reports (e.g. Cobertura, Sonar, Ruby)
• Authentication and user management
• UI Plugins

32. Reasons for CI
• Reports Any Build Failures to the Team
• Reduces the Risk of Integrating Code
Private builds –> integration builds –> release builds
• Establishes Greater Confidence in the Product
– Incorporated automated unit test in the build
• Improves the Efficiency of the Team

35. Reference:
• Internet