(Ruben Spekle, Senior Program Architect) In this session, understand how to set up an efficient and effective release management process. Discuss process best practices and tools to innovate, validate and deploy Salesforce functionality continuously. An effective release train helps you to reduce 'time-to-market' for your stakeholders.

1. Release Management
Setting up the Release Train
rspekle@salesforce.com
​ Ruben Spekle
​ Program Architect

2. Introductions
in/rubenspekle
@Ruben_Spekle
Ruben Spekle
Program Architect
BACKGROUND
• Over 20 years of experience in the IT industry. Last 10 years as an Architect helping
customers with bespoke development programs and packaged based
implementations.
• Responsible for business development in customer experience with Cloud
computing. Creating POC’s, demo’s and thought leadership on leveraging Cloud
Computing to deliver more value to the end customer. Activities include Customer
Journey mapping, Omni channel strategy, Social Media strategy, Integration
strategy, Cloud Governance.
EXPERTISE
• Salesforce Administrator
• Salesforce Advanced Administrator
• Salesforce Developer
• Salesforce Sales Cloud Consultant
• Salesforce Service Cloud Consultant

3. Release Management
Effectively and efficiently delivering solutions to your stakeholders

4. Key Elements of a Salesforce Governance Framework
• Center of Excellence (CoE)
The process of managing governance.
• Change Management
The process to manage the overall program or
project lifecycle – from collecting Business
requirements to moving code from development
through production.
• Org Strategy
The design and structure of the foundational “orgs”
or areas where the customer’s Salesforce
applications will reside and run.
• Technical Governance
The guiding principles for effectively developing the
technical aspects of Salesforce.
Center of
Excellence
Change
Management
Org Strategy Technical
Governance

5. A story: why is release management important?

6. Spoiler Alert!

7. Spoiler Alert!

8. The software development life cycle
​ Business
• Users
• Stakeholders
​ Technology
• Delivery
• Support and Training
​ Processes and Roles
• Business Process
• Technology Process
​ Tooling
• Platform
• Metadata
• Migration
P
ROCESSES
PEOPLE
TRUSTED ADVISOR
TECHNOLOGY
Delivering
Value

10. Understand the problem
Just bring it to production!

11. It starts simple
Prod

12. ProdDev

13. ProdDev UAT Staging

14. ProdDev UAT Staging
Dev

15. ProdDev UAT Staging
Dev
Int

16. ProdDev UAT Staging
Dev
Int
Now, lets add fixed release dates.

17. ProdDev UAT Staging
Dev
Int
Now, lets add fixed release dates.

18. ProdDev UAT Staging
Dev
Int
Now, lets add fixed release dates.
And one long running project

19. ProdDev UAT Staging
Dev
Int
Now, lets add fixed release dates.
And one long running project

20. ProdDev UAT Staging
Dev
Int
Now, lets add fixed release dates.
And one long running project
Dev
Test

21. ProdDev UAT Staging
Dev
Int
Dev
Test

22. ProdDev UAT Staging
Dev
Int
Dev
Test
Bugfix

23. ProdDev UAT Staging
Dev
Int
Dev
Test
Bugfix

24. ProdDev UAT Staging
Dev
Int
Dev
Test
Bugfix
• Refreshing
• Reverting
• Data?

25. Source (Blog By Greg Cook): https://developer.salesforce.com/blogs/developer-relations/
2014/12/salesforce1-enterprise-environment-management.html
1. The truth is in the Org
2. Release has manual Changes
3. The truth is in the Org!
4. Refresh Often
5. Citizen Development

26. The house of release management
Release Management
People
Process
Technology

27. Process & People
The foundation of release management

28. Everything works together with Salesforce
Backlog
Release
Management
Development Process
Ideas
Business
Backlog
Sprint
Developers
• Code or
Configure
• Unit Test
• Migration Scripts
Testing
User
Acceptance
Testing Production
Environmental Management
Agile Methodology
Break-Fix

29. Release management’s superhero: the release manager
​ Roles and responsibilities
Accountable Responsibilities Interfaces With
• Manage all aspects of the
end-to-end release process.
• Sign off the release
for implementation.
• Coordinate Scrum, UAT,
and third-party teams.
• Ensure teams follow the
company's established
policies and procedures.
• Follow the service release and
deployment policy and planning.
• Ensure all data migration has
been completed successfully.
• Document outstanding known
errors and workarounds.
• Release documentation,
communications, and training.
• Implement a source
control system.
• Provide a release roadmap.
• Conduct service roll-out planning.
• Manage reports on release progress
and service-level agreements
(SLAs).
• Ensure release acceptance,
including Business sign-off of UAT.
• Security management
• Test management
• Adoption management
• Training management
• Communication management
• Support management

30. Release roadmap and cadence
Break-Fix Minor Releases Major Releases Salesforce Releases
Bug fixes
Business configuration
Targeted monthly.
Has limited testing.
Simple configuration
changes do not impact
day-to-day business
or require significant
training.
There are no
integrations.
Targeted quarterly.
Provides new initiatives.
Often requires significant
testing and training.
Integration with a third-
party system requires
end-to-end enablement.
Many customers link
upgrades with a major
release.
Best Practices Tips:
• Remember key company dates.
• Document and communicate your release strategy.
• Every release should have a testing strategy: regression testing.

31. Areas to consider
​ When thinking about improving or implementing release management
Areas to Consider Salesforce
• Do you have an existing release process or
other technology?
• What are your release types and how often?
• Does each project release based on your
own schedule?
• Does your current release process account
for enhancement or bug fixes?
• How do you validate the quality of the release?
• Salesforce has a 120-day release cycle for new
features. Please schedule your testing to
include these enhancements and bug fixes,
including those for AppExchange packages.
• Salesforce releases system patches. In most
cases, you will experience zero impact, but
you should be aware in case there is impact.
• Salesforce may move your org to a
different instance.
• Do you have multiple orgs?

32. To summarize, why is release management important?
For Projects For Business Challenges
• Your projects are made up of multiple developers
and work streams.
• Your organization has one copy and one version of
everything. Data gets overwritten.
• Your Salesforce projects are becoming
more complex.
• Large projects often suffer from not implementing
tools and processes early enough.
• Large organizations need rigid change
management processes and tight control
over system deployment.
• More and more, organizations need to have
smaller releases at a higher frequency while
minimizing risk.
• A poor deployment process results in:
• Reduced user adoption and ROI.
• Less-scalable applications.
• Salesforce has limited capabilities for
release management.
Best Practices Tip: A good migration solution reduces operational risks.

33. Tools: Code Migration &
Source Control
Best Practices and Tooling

34. Let’s look at the effects of poor release management
​ The consequences of a poorly managed software release or environment
include:
• Too many sandboxes.
• Lack of ownership.
• No clear path to production (change set,
ANT, managed package, or manual).
• Low-quality coding and testing.
• Conflicting release calendars.
• Frequent conflicts with code and configuration.
• Unclear system integration maps.
• No planned refresh schedule.
• Developers, testers, and release
engineers under constant stress.
• Unsuccessful deployments.
• Changes made directly in production.
• Overall low quality and adoption.

35. Deployment tooling options
Eclipse IDE Change SetsMigration Toolkit

36. An overview of migration tools
Tool Best For Limitations
Change Sets • Sandbox to production migrations
• Change management without source control
• Auditing previously deployed changes
• Enforcing code migration paths
• Deploying the same components to multiple orgs
• Small implementation
• You can only move metadata between a production
or and its sandboxes.
• You can't delete components.
• There is no support for source control.
Eclipse IDE • Project-based development
• Deployment to any org
• Synchronizing changes
• Some setup is required.
• It’s not always upgraded at the same time as other
Salesforce products.
• It has repeatable deployments that require re-selecting
components, which can be time consuming and can
introduce errors.
Force.com Ant
Migration Toolkit
• Scripted and scheduled deployments
• Repetitive tasks using the same set of components
• It requires a more developer-oriented skill set (familiarity
with Ant, scripting tools, and CLI).
• It requires storing a username and password on a disk,
which may be against your security policies.

37. An overview of migration tools
Tool Best For Limitations
Force.com Workbench • Ad hoc queries
• Metadata describes
• Lightweight data loads
• It’s not an officially supported product.
• It does not have project management features.
Force.com Command-
Line Interface (CLI)
• Passwords prohibited from being stored on disk due
to security polices
• Required interactive login
• Scripting and automated tasks
Logging in may be difficult behind a firewall.
Unmanaged Packages • One-time setup of a development environment
• A starting point configuration that is customizable
You can't make further changes to packaged
components using subsequent packages.
Managed Packages • Commercial applications
• You want to add to multiple orgs,
possibly non-related orgs
• Access to code is limited or hidden.
• Unique namespace can be bothersome or a blocker.
• Difficult to modify or delete components.

38. Source control best practices
Commit early and often:
Commits should be small and should work together.
Push code to the system at least daily.
Accompany every commit with a short description
of what is being committed.
Code should be assigned to one of at least
four branches:
Trunk, development, integration, and break-fix.
Additional R&D branches can be created simply
for trying ideas.
Make sure releases to QA and production are
tagged centrally.
• Tag release 1.0 as Production_Release_1.0.
• Tags are never modified after they are created.
Don’t push code that does not build or pass
unit tests.
Do push code that builds, but may not be
perfect yet.

39. Source control: common tools
Subversion
Perforce
Git
BitBucket
Team Foundation Server

40. Source control: tooling considerations
Your current corporate standards.
The Salesforce development tools you are
currently using, if any.
System security requirements:
• Is your system on premises or in the cloud?
• Is the system a private or shared repository?
The experience of your teams.
The integration of other tools selected.

41. Tools: Continuous Delivery
Improving the process of software delivery

42. What is continuous delivery?
Techniques used to enable this process:
• Source control.
• Automated testing.
• Continuous integration (CI).
​
​ The goal is to give the delivery group:
The ability to rapidly and repeatedly
push project enhancements and bug
fixes to production at a
low risk and minimal manual
overhead.
* http://en.wikipedia.org/wiki/Continuous_delivery
Design practice used in software development to automate
and improve the process of software delivery.*

43. Why should you use continuous delivery?
• A Scrum team can deliver capabilities from multiple projects within the same org, and faster.
• Scrum teams can “go fast and iterate.”
• It allows update releases to be made quickly.
• You can drive quality with continuous testing of enhancements and migration scripts.
Create a continuous delivery release management process with automation for
the most cost-effective way to support the forecasted demand. This also provides
the least risk to your projects and later, to your Salesforce production environment.
In addition, continuous delivery enables you to adopt an Agile delivery paradigm.

44. How to use continuous delivery
Principles Requirements
• Manage source code using a source
control system.
• Version all Salesforce metadata scripts
and configuration files.
• Frequently commit code (at least once
a day) as a developer.
• Integrate code frequently.
• Build the mainline on the integration server.
• Automate deployment and testing.
• Code migration tool
• Source control system
• Continuous integration engine
• Regression testing tooling

45. Release management and continuous integration
Source
Control
Production
Environment
Development
Testing
Integration
Testing
User
Acceptance
Testing
Apache Ant
Developer
Edition
Developer
Edition
Developer
Edition
Developer
Pro
Partial Data
Full
Developer
Developer
Developer
Update Production

46. Continuous Delivery Tools
Team Foundation ServerJenkins GitLab CI
Cloudbees Bamboo
Subversion
Perforce
Git
BitBucket
Source Control Tools Automated testing
Deployment tools
Integration tools

47. Coming up: Salesforce DX (beta)
Learn more here

48. Wrap up

49. Steps in setting up the release train
Processes People Technology

50. Learn more
​ Trailhead: Change Management Module
​ Accelerator: Introduction to Software Development Life Cycle
​ Accelerator: Quickstart to Environment Management
​ Circles of Success: Weathering the Storm of Change Management
​ Whitepaper: Introduction to Software Development Life Cycle
​ Whitepaper: DevOps
​ Trailhead, accelerators, circles of success