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.
Grillot Jacques Patrick Boyle Teja Amerineni
Technical Architect - ICMARC Strategic & Enterprise Sales DevOps Practice Lead & evangelist
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)
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
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.
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 !!!!!!!!!!!!!!!!
How We Did It
People
Process
Technology
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,
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.
• 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
ENVIRONMNET CODE FLOW PATERN
Value Definition
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

Salesforce – Proven Platform Development with DevOps & Agile

  • 2.
    Forward-Looking Statements Statement under thePrivate 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 PatrickBoyle 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 manualeffort 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 AgileFramework (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 outcomeof 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 DidIt People Process Technology
  • 9.
    People Knowledge around version controlwas 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 developmentmechanisum • 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 AutoRABITas 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.
  • 13.
  • 14.
    Roadmap and SalesforceDX  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