AutoRABIT presented on proven platform development with DevOps and agile at TrailheaDX 2018.

2. Forward-Looking
Statements
Statement under the Private Securities Litigation Reform Act of 1995:
This presentation may contain forward-looking statements that involve risks, uncertainties, and
assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the
results of salesforce.com, inc. could differ materially from the results expressed or implied by the
forward-looking statements we make. All statements other than statements of historical fact could be
deemed forward-looking, including any projections of product or service availability, subscriber
growth, earnings, revenues, or other financial items and any statements regarding strategies or plans
of management for future operations, statements of belief, any statements concerning new, planned,
or upgraded services or technology developments and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with
developing and delivering new functionality for our service, new products and services, our new
business model, our past operating losses, possible fluctuations in our operating results and rate of
growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of
any litigation, risks associated with completed and any possible mergers and acquisitions, the
immature market in which we operate, our relatively limited operating history, our ability to expand,
retain, and motivate our employees and manage our growth, new releases of our service and
successful customer deployment, our limited history reselling non-salesforce.com products, and
utilization and selling to larger enterprise customers. Further information on potential factors that
could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K
for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal
quarter. These documents and others containing important disclosures are available on the SEC
Filings section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or
public statements are not currently available and may not be delivered on time or at all. Customers
who purchase our services should make the purchase decisions based upon features that are
currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these
forward-looking statements.

3. Grillot Jacques Patrick Boyle Teja Amerineni
Technical Architect - ICMARC Strategic & Enterprise Sales DevOps Practice Lead & evangelist

4. What is DevOps?
 Dev Ops Team is a interfacing team Between Development ,
Operations ( Support) & QA teams
 It Governess the policy around Environments , Deployments ,
Practice & Tools
 DevOps is the practice of Operations and Development teams
participating together in the entire Application development
lifecycle
 This spans from Design, through the Development process to
Production Support
 The Goal is todays developed code is ready to go to production
by end of day fully tested ( Including Regressions)

5. Pre-Context
Change Sets
Too much
manual effort
co-ordination between
Developers for
change sets - Manual
Source of truth –
Salesforce Org
Overwritten code/
configuration
due to change sets.
Loss of ROI on
salesforce platform

6. SAFe Framework
Scaled Agile Framework (SAFe)
• Unified Backlog for multiple Scrum team.
• Better Program and Portfolio management without Oversized teams
• Improved knowledge sharing and reduction of Silos
• Release Cadence with Program Increment [ PI ] Model with teams
getting aligned to the timeboxed process.

7. Why DevOps
The outcome of SAFe model:
Process improvements need Automation for sustenance
One Sandbox cannot be the source of truth with multiple projects to run in Parallel
Better Governance on the release environments to control manual changes on them.
This has transitioned the journey into DevOps !!!!!!!!!!!!!!!!

8. How We Did It
People
Process
Technology

9. People
Knowledge around version
control was limited.
Admin/Developers had no
idea on what is GIT and
how it can be used
Not just admins/developers but
scrum masters, product owners and
portfolio stakeholder were also been
involved in the “change” with
adequate training/coaching sessions
[ outside of Scrum ceremonies]
• The Developer learning curve is
drastically reduced
• a lead developer role has been designed
to review the validation reports and
code/config changes for better stability
and enable early warning for developers.
• All the Test classes are validate ahead of
the commit process only
With AutoRABIT Gated-Checkins,

10. Process
Introduced test driven
development mechanisum
• No changes can be made above Development
directly in environment
• The deplores should start their development on
every day basis on the latest code only
Governing Policies for change
management across various
environments.
Moved from quarterly
release to monthly release
Define quality gates
each stage of release
to ensure smooth
operations in
production.
Release Calendar aligned with PIs
taking into account Salesforce
releases as well as Organizational
blackout periods.
Release Dates are locked
and require VP to approve
any changes.

11. • Introduced AutoRABIT as our DevOps Tool
• Source Control with GIT driven by AWS Code Commit .
• Agile Management System – Program increments are managed in CA Agile Central (Rally)
• Code Security Tools – Integrated with Code Security tools to make security as a practice into development.
• Continuous Integration and Continuous Delivery tool – Need a platform that was low maintenance and could integrate all the above tools
with Salesforce.
• Automation testing is introduced to make sure the development is fully regression tested and reduce the Manual efforts
Technology

12. ENVIRONMNET CODE FLOW PATERN

13. Value Definition

14. Roadmap and Salesforce DX
 Continuously improving processes as part of PI lessons
learned.
 Establishing a test data infrastructure to support
integration and data validity across environments.
 Empowering business unit admins with more abilities to
offload work from development teams.
 Foundation is in place to support Salesforce DX.
 Deploy branches and data to scratch orgs.
 Pilot with hotfix branches as well as with advanced
developers.
SPONSOR