This document discusses how to run a successful OpenCms project using Agile methodology. It describes NorthPoint, an organization specializing in open source technologies. The document covers using Agile development with OpenCms, including maintaining flexible requirements, test-driven development, and continuous integration. It discusses setting up development scripts and continuous builds to deploy code changes to OpenCms on a regular basis.

1. September 25, 2012

2. INTRODUCTION
About me and NorthPoint…
+ NorthPoint is a USA-based organization with offices in New
York and Boston
+ Specializing in Open Source technologies for web applications
+ 130+ on-staff technologists focusing on Digital Strategy,
Content Management and Enterprise Digital Architectures
+ Areas of focus in Media, Publishing, Finance, Healthcare,
Education, and Not-for-Profit markets

3. WHAT WE WILL DISCUSS TODAY
 Running a successful OpenCms project leveraging Agile
 Maintain flexibility of requirements
 Deliver high-quality OpenCms implementations through use
of TDD & Continuous Build
 Agile Development
 Overview
 How we run Agile with OpenCms
 Development of Deploy Scripts and Continuous Build

4. RUNNING A SUCCESSFUL
OPENCMS PROJECT
LEVERAGING AGILE
 Agile Development Process
 Why use Agile?
 Everyone has their own take on Agile – “Part of the Issues”
 Review of “True Agile” development
 Tying in Agile with Extreme Programming Techniques
 Agile approach for OpenCms projects

5. WHY CHANGE? WHY AGILE?
 Why should we change from traditional
project management and development
methods?
 The traditional method breaks down during the
lifecycle of the project
 Change Request
 Changes in business
 The applications winds up being different from what was
originally documented and envisioned
 Feedback from the customer is at the end of the process

6. TRADITIONAL SOFTWARE
DEVELOPMENT
 Business Analysis and Systems Analysis and the Design
has been signed off by the customer
 Development begins
 Change Requests begin
 More functionality changes and tweaks later and things are not
looking good
 The schedule begins lagging
 Client’s first BETA and even more changes are requested
 Chances are, it's a mess of coding and comments without proper
notes and testing and by now every little change here breaks
something there

7. CURRENT APPROACH –
WHY IT FAILS?
The Methodology didn’t The Solution didn’t
work work

8. TRADITIONAL FEATURE &
FUNCTION USAGE

9. WHAT CAN WE DO?
 New techniques are being used to break this familiar
mold of software development
 They are known as Extreme and/or Agile development
 Developing OpenCms custom modules with Agile is the
way to go

10. AGILE – A QUICK OVERVIEW
 Scrum – an iterative, incremental process
 All work is done in Sprints
 Sprints last for 30 days
 Every day the team gets together for a daily Scrum that
lasts 15 minutes
 Incremental, potentially shippable product functionality
every 30 days

11. HOW IT WORKS WITH OPENCMS
 Although following Agile to the letter sounds good, in
practice we have made some slight variations
 Upfront Analysis and Definition of Scope
 Source Control, Continuous Build and Continuous
Integration
 Full QA at the end
 Planning ahead for next phases

12. TEAMS AND CODE MANAGEMENT
 Creating Epics, Stories and Tasks
 Using the Stories to create test cases – the beginning of
TDD
 Leveraging JUnit for custom code
 We use Jira to help run things
 Multiple teams need a good solution
 Continuous is the only way

13. TEAMS AND CODE MANAGEMENT
The tools we use
 Jira – Greenhopper, Crucible, Fisheye and Hudson along with custom
Scripts
 Greenhopper – used for bringing things together
 Estimating, Velocity, Burn downs, etc.
 Crucible is a web-based tool that we use for in-line commenting, code
reviews (allows for collaboration between author and reviewer)
 We feel this is a better approach than paired programming
 Fisheye for continuous build along with Hudson. Fisheye helps when
trying to connect SVN commits through hooks in the code review process
leveraging Crucible and Fisheye, in conjunction with automated quality
test through sonar

14. ISSUES WITH AUTOMATION
AND OPENCMS
 The issues with integrated testing and automated builds with
OpenCms is the way things work in OpenCms
 Much of the code is in context sensitive situations where part
of the code is in Java, part in JSP’s and the rest in OpenCms
core
 To create an automated process you need to be able to test
across these different types of code
 What we created is a combined integration and test server
where code is automatically compiled and deployed
 Once it’s deployed, tests can be triggered against the code
through Selenium scripts for front-end testing

15. MAKE IT WORK
 Commitment to change
 Leveraging Test Driven Development (TDD)
 adding a test, then making it work
 Develop the backlog
 Creating the right team mix

16. WHAT’S NEEDED WITH OPENCMS
 Maintain a Code Repository
 SVN, Github
 Automate the Build Process
 Maven
 Make the build Self Testing
 Test Driven Development (JUnit for Java Classes)
 JSP’s require a different approach
 Automate Scheduling and Deployment
 Hudson

17. CONTINUOUS BUILD PROBLEMS
 Modules and source code are deployed to the VFS
 VFS is located in the Database
 Modules need to be packaged (zipped) into OpenCms module
format in order to be imported
 What about importing non module code into the VFS system
folder?
 What if we did not want to import an entire module but only
parts of it?

18. OUR ANSWER
Create Scripts
 Create a script that packages source code into
OpenCms-ready module
 Create a script which will prepare source code to be
synchronized in OpenCms using the workplace
synchronization tool

19. Sync System and
Make Modules Scripts
Two shell scripts which prepare
source code to be imported and
synchronized with OpenCms

20. NEED TO SET
ENVIRONMENT VARIABLES
+ export TOMCAT_HOME=/usr/local/tomcat
+ Location of app server where OpenCms is running
+ export DIR_SVN=/usr/local/src/svn/trunk/opencms
+ Location of your subversion directory and src code
+ export OPENCMS_HOME=/usr/local/tomcat/webapps/opencms
+ Location of the OpenCms deployed web site running inside of AppServer
+ export SYNC_DIR=/usr/local/src/opencms/sync
+ Directory which will be used to sync content between the file system and OpenCms
Virtual File System (VFS)
Environment variables need to be set in order to execute the shell
scripts. Scripts will use the environment variables making it easier to
move scripts in between different environments with little effort
*Environment variables can commonly be set in a users .bash_profile file

21. WHERE ARE SCRIPTS?
 Scripts live in the bin directory in your source code home
directory (DIR_SVN)
 Module source code lives in the modules_src directory
Subversion Home Directory

22. MakeModule.sh
This script will take source code from
Subversion repository and zip up the code
and deploy it to the OpenCms server. User
will then be able to login to the admin and
upload the module via the module
manager.

23. MakeModule.sh
+ Executing the Script
+ Pass in the environment (dev)
+ Used if there are multiple instances (dev, test
prod) of OpenCms running on one machine
+ Pass in the module name
(edu.chop.migration)

24. MAKE Module.sh RESULTS
+ Module code copied from the modules_src directory
and zipped up and ready for deployment
+ Module code copied and deployed to the OpenCms
package directory
/WEB-INF/packages/modules/

25. MakeModule.sh LAST STEP
Log into OpenCms admin and deploy the module

26. syncSystme.sh SECOND SCRIPT
 This script will sync source code to OpenCms by
copying code to a sync directory (SYNC_DIR) and
then using OpenCms to import the files from that
directory using the OpenCms synchronization tool

27. syncSystem.sh
Step 1
– Configure synchronization settings in OpenCms
+ Synchronization setting will need to be configured to point to your file system
sync directory. Also we need to specify which folders in the VFS we want to
sync

28. syncSystem.sh
Step 2
+ Sync Down
+ Before we sync files from the file system into the VFS
we first take files out of the VFS and put them on the
file system
+ We want to tell the script which folders we want to
sync
+ Gives the sync folder an up-to-date snapshot of
the current source code in the VFS
+ Synchronizing will overwrite files and does not
create new ones

29. syncSystem.sh
Step 2 cont...
– Click on the sync button on the top right of screen

30. syncSystem.sh
Step 3 Run Sync Module Script
Go to your Subversion home directory
Run the script

31. synsSystem.sh RESULTS
Sync Folder updated

32. synsSystem.sh
Step 4 Sync Up
- Running the synchronization again will push
the files from the file system up to the VFS

33. syncSystem.sh
 Sync is complete!

34. RECAP OF AN OPENCMS PROJECT
USING AGILE AND CONTINUOUS
BUILD
 Agile process for better management of requirements
and working with the end user
 Jira and third-party tools for:
 Managing Code
 Automated Testing
 Keeping Multiple Teams in Sync
 Custom Scripts for Continuous Build
 Supported by tools such as Hudson and possibly Gradle in
the future

35. RICH COOLEY
rich_cooley@northps.com
TALK TO US. CHALLENGE US.
CALL US at 212.819.1700
VISIT US at www.northps.com
FOLLOW US @northps
© NorthPoint and NorthPoint Solutions LLC