Continuous delivery (CD) allows software updates to be released frequently by having each code change trigger automated builds, tests, and deployments. This document discusses best practices for implementing CD for Alfresco solutions, including using consistent project templates built with Maven or Gradle, packaging modules as AMPs, externalizing configurations, supporting multi-module deployments, using deployment frameworks like Chef, and deploying to test instances on private clouds. Common pitfalls to avoid are unrealistic time planning, lack of involvement from system admins, and developers not understanding the importance of green builds.

1. Continuous Delivery for Alfresco Solutions
Satisfied customers and happy developers with
Continuous Delivery

2. About me
• Roeland Hofkens
• #rhofkens
• roeland.hofkens@westernacher.com
• http://opensource.westernacher.com
• CTO Westernacher Products and Services AG
• Over 15 years of ECM experience
• Over 3 years of Continuous Delivery experience

3. Introduction
• Embrace Continuous Delivery for:
• Satisfied customers
• Happy developers
•How can we use CD successfully in Alfresco Solutions?

4. Agenda
• What is Continuous Delivery?
• How can CD be used for Alfresco Solutions?
• Best practices
• Pitfalls
•Live demo
• Demonstration of Continuous Delivery in the Westernacher
Development Environment

5. What is Continuous Delivery (CD) ?
• Cornerstones of Continuous Delivery
• Each check-in creates a potential release
• Each check-in (or a batch of check-ins) triggers a build & the related tests
• Each build is automatically deployed on a production-like test system
• Automated tests are executed on the newly deployed system
• “Infrastructure is code”
• All steps in the process are fully automated. Tools are required.
• Landscape configuration is externalized and versioned
• Each step provides immediate feedback (success & failure)
• Enables the developer team to act on it immediately
• What does this mean?
•At each moment in time we have a verified build that could
potentially be released to production

6. Continuous Delivery in context
Level of Complexity
Continuous
Easy
Integration
Level of Automation
• Each check-in creates a build
• Code level analysis
• Unit testing
• Guarantees code quality and consistency across the team

7. Continuous Delivery in context
Level of Complexity
Continuous
Challenge Delivery
Continuous
Easy
Integration
Level of Automation
• Each check-in creates a release candidate
• Fully automated deployment to test production-like env.
• Push-button deployment to production
• Guarantees that code is always in a state that can be
release to production
• Guarantees availability of latest features for customer
testing at all times

8. Continuous Delivery in context
Continuous
Complex
Deployment
Level of Complexity
Continuous
Challenge Delivery
Continuous
Easy
Integration
Level of Automation
• Each check-in produces a new production release
• Requires 100% test coverage and trust in the build
• Sophisticated deployment techniques required
• Guarantees availability of latest improvements to end users
at all times

9. Continuous Delivery toolset Tests
Coverage
Ticket Build Analysis
System Server
Smoke Tests
Load Tests
IDE Deployment
Artifact
DEV ENV Framework
Repo
Source Code Virtual Manual QA
Control System Machine

10. jUnit
CD Toolset @Westernacher Tests
Sonar
Coverage
JIRA Bamboo
Selenium for
Ticket Build Analysisand UI tests
Smoke
System Server
Smoke Tests
jMeter for
Load Tests tests
load
Eclipse Artifactory Chef
IDE Deployment
Artifact
DEV ENV Framework
Repo
SVN, Git VMWare
vSphere
Source Code Virtual Manual QA
Control System Machine

11. Continuous Delivery advantages
• Satisfied customers

12. Continuous Delivery advantages
• Happy developers

13. CD & Alfresco: Best practices (1)
• Use consistent Alfresco project templates
• Every project has the same structure
• 3 levels:
• Root
• Repo
• Share
• Every project is built in the same way
• Version your templates

14. CD & Alfresco: Best practices (2)
• Build with Maven or Gradle
•Use dependency resolution
• Alfresco now offers a Maven Repo
• Can also be accessed with Gradle
•Westernacher uses Gradle
• Increased flexibility
• Groovy DSL for build tasks
• AMP Plugin for Gradle

15. CD & Alfresco: Best practices (3)
• Use AMPs to package your
deliverables
• Always create two AMPS
• Repo
• Share
• Don’t put landscape dependent config in
your AMPS
• alfresco-global.properties
• share-config-custom.xml
• Develop an AMP that shows build
information in Alfresco

16. CD & Alfresco: Best practices (4)
• Only build your binaries once
1
• One binary fits all landscapes
• Regressions not possible
• Configuration is externalized
• Stored in SCM
• Versioned and managed as code
• Fed into deployment framework

17. CD & Alfresco: Best practices (5)
• Support multi-module deployments
• Design modular solutions
• Package all your extension in AMPS
• Solutions are composed of multiple AMPS
• Use flexible deployment configurations
• Module composition in configuration file
• Linked to artifact repo to allow dependency
resolution and versioning

18. CD & Alfresco: Best practices (6)
• Use a deployment framework
• Deployment frameworks take the pain
out of deployment tasks
• Repositories with scripts available
• Handle the externalization of configuration
easily
• Westernacher uses Chef
• Open Source with commercial support
• Large community
• Ruby scripting, JSON config

19. CD & Alfresco: Best practices (7)
• Deploy two instances on the same
2
VM
• Continuous Build instance
• Redeployed on every build
• Verifies delivery
• Dynamic environment for automated testing
• Nightly Build instance
• Only runs when CB build is green
• Stable environment for manual QA testing

20. CD & Alfresco: Best practices (8)
• Support shallow and deep
2
deployments
• Deep
• Set up complete Alfresco system from scratch
• Clean DB, repo and indexes
• Shallow
• Only update web apps
• Don’t touch the repo

21. CD & Alfresco: Best practices (9)
• Create Alfresco data loaders
• Data is needed for automated testing
• Bootstrap initial settings using Alfresco
bootstrap mechanisms
• Folder templates
• Categories, users, …
• Use your REST APIs to load data
• Can double as load tests
• Excellent sample code on how to use your
API

22. CD & Alfresco: Best practices (10)
• Use the (private) cloud
• Fact: you’ll need plenty of VM’s
• Create VM templates with OS
• Include basic environment and chef client
• Public cloud e.g. Amazon EC2
• Ideal for load testing
• Ideal for short research projects
• Private cloud
• Westernacher uses vSphere 5
• Cost effective for daily use

23. CD & Alfresco: Common pitfalls (1)
• Unrealistic time planning
• Setting up a CD environment is a
complex task
• Take your time
• Allow lots of room for “refactoring” of the
pipelines
• Work Agile
• Same rules apply as for software projects
• Short cycles, deliver often

24. CD & Alfresco: Common pitfalls (2)
• No involvement of system admins &
IT stakeholders
• Involve your system administrators
• Make sure they understand the need
• Show the advantages for sys admins
• Have the sys admins create the cookbooks &
recipes
• Plan in compliance to IT policies from
the start
• Changing afterwards is a big effort
• Increase acceptance

25. CD & Alfresco: Common pitfalls (3)
• Developers don’t understand the
importance of a green build
• Evangelize CD
• Communicate the advantages
• Everybody in the team is responsible for the
build
• Make CD easy
• Show working examples
• Create end-to-end sample pipelines for copy &
paste

26. Live Demo: An Alfresco CD Build Pipeline

27. Questions & Answers

28. Thank you!