This is Greg Montaño's slides on "Version Control and Continuous Integration", which was presented at the Cebu StackOverflow Meetup on 26 May 2012.

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