Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Salesforce DevOps for Architects
Salesforce DevOps for Architects

Salesforce DevOps for Architects: Discover tools and techniques to optimize the delivery of your Salesforce projects

Arrow left icon
Profile Icon Cowell Profile Icon Lars Malmqvist
Arrow right icon
£20.98 £29.99
Book Jan 2024 260 pages 1st Edition
eBook
£20.98 £29.99
Print
£27.99 £37.99
Subscription
Free Trial
Renews at £16.99p/m
Arrow left icon
Profile Icon Cowell Profile Icon Lars Malmqvist
Arrow right icon
£20.98 £29.99
Book Jan 2024 260 pages 1st Edition
eBook
£20.98 £29.99
Print
£27.99 £37.99
Subscription
Free Trial
Renews at £16.99p/m
eBook
£20.98 £29.99
Print
£27.99 £37.99
Subscription
Free Trial
Renews at £16.99p/m

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon AI Assistant (beta) to help accelerate your learning
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Table of content icon View table of contents Preview book icon Preview Book

Salesforce DevOps for Architects

Developing a DevOps Culture

The core of a successful DevOps implementation does not lie with the technology and tooling used. Instead, getting the surrounding team culture in place and aligned with a new way of working is the most essential element that underpins DevOps.

In this chapter, we will cover the importance of the offline aspects of DevOps, and how a culture of collaboration and communication is fundamental to DevOps success. We’ll see ways in which to drive adoption and alignment with best practices in your organization. Along the way, we’ll explore the following:

  • Why culture is key to a DevOps transformation and how we can start building it
  • The need to strive for strong communication that drives collaboration
  • Ways to drive adoption of and alignment to a DevOps approach

The need for a DevOps culture

The history of software development and its delivery has been long and ever-changing. As the landscape of technology has changed, so has the need for businesses to get that technology into the hands of customers. DevOps represents a drive to deliver according to that need, replacing monolithic software releases, lengthy project cycles, and opaque waterfall methodologies.

When we look at DevOps as a way of delivering change, it’s very easy to get pulled into looking at the software tools first, but this should not be where your DevOps journey begins. It’s equally important to keep in mind that any DevOps transformation should not be prescriptive; instead, it should align with you and your organization’s way of working. This approach is equally important for those that have had prior DevOps experience with other teams or systems – there is no “one size fits all” approach to DevOps, and while experience can be brought to bear on building a DevOps culture with a new team, you should be mindful of tailoring it to fit the team.

However, there are some common elements that work consistently for high-performing DevOps teams, so you should contemplate making these a part of your plan to bring DevOps culture to life. Let’s begin by looking at some of the characteristics of successful DevOps teams and the elements of DevOps culture they have adopted, before diving deeper into how to deliver them.

Strongly defined teams

As the name suggests, DevOps teams are a hybrid of IT Development and IT Operations teams, but the reality is not as straightforward. Successful DevOps teams comprise teams from the full end-to-end spectrum of software delivery, from business analysts gathering the requirements and architects designing solutions to those requirements through to developers implementing those solutions and operations delivering those requirements in your Salesforce environments.

It is within this cross-functional team structure that you need to establish strong buy-in for DevOps. A team that does not understand or appreciate the value of a process is unlikely to adopt DevOps – and it only takes a few shortcuts or out-of-process releases to damage the good work the rest of your DevOps team has done. It is vital that the entire team aligns and engages with DevOps as a way of working, to make the initiative successful.

A team that aligns with DevOps practices has shared responsibility for the entire application life cycle, from planning to deployment and maintenance, thus reducing standoffs and finger-pointing over who is responsible for fixing bugs or test failures. Additionally, DevOps encourages product teams to be more involved in the development process, ensuring that their input and expertise are considered throughout the application life cycle.

As architects, we need to convey the value that DevOps brings since for most teams – whether technical or on the business side – this tends to be the key factor that gets people on board. By showing how DevOps benefits everyone along the development journey we have outlined, we stand a better chance of getting teams on board with DevOps, compared to a hard enforcement of processes.

Companies that have yet to adopt a DevOps culture for software delivery may have lost trust in their delivery teams, bringing in heavyweight processes in an attempt to prevent the risk of future failures. Part of adopting a DevOps culture is restoring that trust by providing tools and processes that empower teams to succeed and allow any failures to be small, rather than bogging everything down by trying to avoid failure entirely.

In general, one of the benefits of DevOps and Agile is to be able to take small steps safely. DevOps and Agile methodologies advocate for small, incremental releases rather than large, monolithic deployments. This approach allows teams to identify and fix issues more quickly, reducing the risk of catastrophic failures. It also enables them to respond to changing requirements or market conditions more effectively. As a result, trust in the team’s ability to deliver accurate results and adapt to change grows.

Closely working together

Hand in hand with strong teams is the need to collaborate and communicate with each other. This may seem an obvious need in all working teams, not just DevOps, but the principles of clarity, visibility, and cooperation really come to the fore with DevOps and are essential for its smooth running.

To break down the siloed approach to software delivery and work toward a common goal, the entire team needs to be aware of how projects are being delivered. Techniques such as Agile and tools such as Jira or Asana will certainly help with this, but that’s only part of the picture of collaboration, as we’ll explore shortly.

Constant evolution

No matter how mature a DevOps team may be, the highest-performing teams are always open to change and improvement. Through a continuous cycle of measurement, enhancement, and re-measuring, these teams are able to pinpoint areas where performance and accuracy gains can be made and then address them. The most common metrics they tend to focus on are based on the DORA metrics, as follows:

  • Deployment frequency: How often a team releases to production
  • Change lead time: How long it takes for a specific feature to reach production
  • Change failure rate: The proportion of deployments that either fail to deploy or cause errors in production
  • Mean time to recovery: How long it takes to recover from a production error or another issue

In the context of Salesforce, measuring against these metrics can be a bit different since it’s a cloud-based platform with specific features and limitations. Metrics such as deployment frequency, change lead time, and mean time to recovery can be determined easily enough, especially if you have a ticketing system such as Jira or Asana for managing new work.

The change failure rate can be a little trickier, though, since it involves tracking unsuccessful deployments and the number of incidents or defects related to those deployments. There are a few ways you could approach this – we’ll cover Salesforce-specific DevOps solutions and platforms in later chapters, but as an example using on-platform features, you could try the following:

  • Use Salesforce’s deployment history, available on the Deployment Status page, to track the success and failure rates of deployments. Identify failed deployments and the specific components that caused the failure.
  • Keep a record of all production incidents, including those caused by recent deployments. You can use the Salesforce Case object to log and track incidents.
  • For each failed deployment or production incident, analyze the root cause and determine whether it was due to a recent change. You can use the Salesforce Developer Console, debug logs, and test results to pinpoint the root cause of the issues.
  • Divide the number of failed changes (deployments causing incidents or defects) by the total number of changes made during a specific period. Multiply the result by 100 to get the change failure rate as a percentage.

The origin of the DORA metrics

The DORA metrics came from a group called DevOps Research and Assessment, which was founded in 2015 by Nicole Forsgren, Gene Kim, and Jez Humble (and later acquired by Google in 2018), to better understand what factors led to high-performing DevOps teams. Since that initial research, these four metrics have become an industry-standard set of measurements of DevOps success.

Now that we’ve determined the need for, and elements of, a strong DevOps culture, let us look in more detail at some techniques for creating this culture.

Collaboration and communication

In an ideal DevOps team, the whole team works in the same way and toward the same goal – there should be a shared responsibility for the successful delivery of changes. Fundamental to this collaborative approach is strong communication, and this can take many forms, from the more formal approach needed for governance of the overall change management process down to the daily interactions that form part of your usual workflow.

Communication should be clear, informative, and present at every step of the delivery life cycle. For example, when using version control, teams should endeavor to always provide meaningful commit messages and comments on peer reviews. These aid teams to carry out the next steps of any change delivery process with context, not just the specifics of the change itself. There is often a balance needed between providing sufficiently detailed information and relevant information, and you should iterate on this level of detail to find the sweet spot that works for you and your team.

While this book is not an exploration of Agile principles, there does seem to be a strong correlation between successful DevOps teams and Agile practitioners since both disciplines foster these same principles of regular, clear, and concise communication to drive projects forward. Such techniques encompass all team members involved in delivering change so that everyone is informed and aware of the process and progress of work.

Equally, tools will help bring visibility and clarity to daily work. Software for managing features as they go through your DevOps process, such as Jira, Asana, Azure DevOps, and so on, can bring this overview to your processes when used properly and they integrate in some way into most DevOps tools to complete the picture. Many teams have started to eschew email as an internal communication medium, instead favoring the immediacy of messaging platforms such as Slack or Teams as a further means of breaking down siloes and removing barriers between cross-functional teams.

The necessity of adapting to remote work has led to an increased reliance on digital communication tools and has changed the dynamics of team interaction in a number of ways. With teams distributed across various locations and time zones, it is essential to have tools that enable real-time collaboration and offer instant communication, file-sharing, and integration with other tools. In remote work, it is not always possible to gather everyone at the same time for discussions. Asynchronous communication tools, such as project management platforms, shared documents, and threaded discussions on messaging apps, allow team members to contribute at their convenience and keep everyone informed of progress.

With every adaptation that needs to be made with the shift to remote working, balance is key. With the shift to digital communication, remote workers may face an influx of messages and notifications. Messaging platforms have adapted by offering features such as channels, threads, and snooze options, allowing team members to prioritize and manage their communications effectively. However, it is equally important to maintain a sense of connection and engagement between team members. Messaging platforms facilitate informal interactions, such as virtual water-cooler conversations, quick check-ins, and social activities, helping teams stay connected and fostering a positive team culture.

Remote work has made it necessary for teams to communicate effectively without the context provided by face-to-face interactions. Modern methods of communication for distributed teams encourage team members to be more concise and clear in their communications, as well as more intentional with their responses.

Finally, as remote work relies on digital communication tools, ensuring data security and compliance with industry regulations becomes critical. Technological solutions have responded by offering end-to-end encryption, data storage options, and compliance features tailored to different industries.

Adoption and alignment

As we’ve seen, the adoption of a DevOps culture should come before the adoption of DevOps technology. Within each, however, the optimal approach is always to start slowly – it’s often said that DevOps is a journey, not a destination, and to that end, we should begin with some planning.

Questions to start with

The best place to start any kind of journey is to look at where we would like to go, with a few questions:

  • What does the intended process look like?

Knowing your target scenario helps focus your efforts and prevents unnecessary disruption to your business. For example, is the ultimate goal to be able to deliver business requirements faster and incrementally, or do you want to work to a more scheduled, sprint-based approach, but have better visibility and control over the elements contained within that sprint? Having the aims well defined up front helps focus teams on delivering them.

  • What is the intended audience for the new process?

A new DevOps process will impact more than just development and operations teams. If you truly want to adopt an end-to-end Salesforce DevOps approach, you will need to align not just the technical teams but also those involved in the gathering and assigning of work tasks, those responsible for project management, release management, overall architecture, business approval, and more. We’ll look at some of these governance aspects shortly.

  • What do we need to change in our current approach?

While it’s not unheard of, it’s rare that an existing process needs to be completely replaced. Take stock of your current delivery model and make note of what works and what doesn’t work. Where are the bottlenecks that are slowing you down? How many attempts does it take to get something delivered to production? If we look again at the DORA metrics discussed earlier, where are we starting from? Getting a baseline set of metrics before you start a DevOps transformation is a solid way of measuring progress and improvement – and ultimately, your return on investment – as you begin to adopt Salesforce DevOps. Furthermore, having the ability to demonstrate the problem (and later, the improvements made) to executive stakeholders is invaluable in getting their buy-in for a DevOps transformation project.

With these questions front of mind, it becomes easier to start identifying the potential gains from adopting Salesforce DevOps, which, in turn, can help drive team alignment with the change. This step is essential – everybody involved needs to become a stakeholder in the move to DevOps and the best way to achieve this is to look at things from two viewpoints:

  • What are the benefits that DevOps will bring?

After identifying the teams that will be directly impacted by the adoption of DevOps as a means of delivery, work on conveying the benefits to them. Visibility of changes, more manageable and smaller units of work, faster delivery, robust testing, reasonably predictable release cycles – all of these things matter to Salesforce teams and the overriding principle of making their life easier is a strong driver for getting people on board with the change.

  • What are the risks of not adopting DevOps?

Equally, it’s valuable to assess the risks of standing still and changing nothing. If you don’t adopt a faster and more flexible delivery model, you risk being outmaneuvered by more agile competitors. If you don’t implement a robust backup and recovery strategy, you risk losing your valuable business data or that of your customers. If you stick to more traditional delivery models, which can be lengthy and arduous, you risk dissatisfaction and burnout in your teams, which can lead to them moving elsewhere.

Making life easy for your teams

If your Salesforce team is new to DevOps concepts, techniques, or even terminology, then it can seem a daunting prospect for them to move to a new delivery model. However, like all large projects, the optimum approach is often to start slowly with small aspects of the process, then expand and iterate upon it.

For example, because the concept of source control has historically been a code-based domain for developers, many Salesforce Admins will be unfamiliar with this approach. This area alone is a good place to start – even if you don’t necessarily dive straight into applying source control, the mere act of aligning Admins and Developers with a common way of working contributes to the communication and collaboration components of building a DevOps culture.

Having Admins and Developers work more closely together in this way also lends itself to another great set of techniques for fostering your DevOps culture. High-performing Salesforce DevOps teams make frequent use of mentoring and coaching to not only improve the overall skill set and confidence of the team but also as an aid to collaborative working and breaking down siloes to form a multi-discipline DevOps team.

Of course, it’s not all about the process, and you should also ensure that your teams have the necessary tools to aid a smoother DevOps journey. As an architect, you should be ever-mindful of the Salesforce DevOps landscape and assess the components, such as version control providers, new tools or updates to existing ones, or even complete Salesforce DevOps platforms – some of which we’ll look at in later chapters.

Governance and risk management

A DevOps culture should be ever-mindful of the need to manage and mitigate business risks, and a strong governance framework should be in place to provide this. It’s important to appreciate that while DevOps unlocks the potential for rapid delivery of change, it is not a free-for-all without controls.

The governance of our DevOps process should be aligned with the governance in which your business, or that of your customers, operates. Without the correct processes in place, you risk losing the value of the alignment and adoption you fostered in starting your DevOps journey. You risk falling back to the use of lengthy, monolithic releases with dissatisfied customers waiting on changes that are buried deep in the backlog. You also potentially risk low-quality changes being delivered, which, in a worst-case scenario, can damage your systems, your data, and your reputation.

Regulated industries such as financial services and healthcare face unique challenges when it comes to software development and deployment. These industries are subject to a wide range of regulations, standards, and compliance requirements that govern how software must be developed, tested, and deployed. These regulations are in place to protect sensitive data, ensure data privacy, and prevent fraud and other criminal activities.

In financial services, regulations such as the Sarbanes-Oxley Act, Payment Card Industry Data Security Standards (PCI DSS), and Anti-Money Laundering (AML) regulations require financial institutions to implement strong controls around software development, testing, and deployment. Similarly, in healthcare, regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and the General Data Protection Regulation (GDPR) require healthcare organizations to protect patient data and ensure data privacy. DevOps can help organizations in these types of industries comply with these regulations by providing a structured process for software development, which includes automated testing, security scanning, and continuous monitoring. This can help ensure that software is developed with security and privacy in mind and that any potential security vulnerabilities are identified and addressed before the software is deployed.

A good governance framework addresses these issues by implementing the necessary checks and balances throughout the entire life cycle. From prioritizing work and deciding which initiatives are driven forward through to the technical design and implantation considerations, governance allows stakeholders on all sides to input into success.

At the heart of this approach lies the Center of Excellence, which oversees this journey. It informs and guides the business goals as they apply to Salesforce, the approach used for delivery, and the technologies used. It is also responsible for communication with both stakeholders and end users across the organization, for identifying and managing business risk of projects, and for ensuring initiatives deliver value.

As such, a CoE often contains, or works alongside, distinct groups with specific responsibilities. A Change Management group, for example, will be the approving body for changes going into Salesforce and will make sure that the change is of suitable quality and has been thoroughly tested before it is allowed to be released to production. This would typically be through the definition of the required processes and behaviors it expects to see carried out to ensure quality deliverables, rather than it carrying out the testing itself, which would continue to be the responsibility of the technical teams.

A note of caution should be taken with Change Management groups, however. In the book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble, and Gene Kim, the authors emphasize the importance of fast feedback loops, continuous experimentation, and a culture of learning and improvement – factors that may suggest that traditional change management practices may not always align with the needs of high-performing DevOps teams.

A Steering Committee, on the other hand, is a business-led group that ensures that changes continue to align with business strategy, vision, and values. Across all these areas, there should be an executive sponsor that is empowered and available to make decisions and unlock business bottlenecks.

Making a case for a CoE to leadership

Architects looking to present a case for establishing a CoE to the leadership of their organization or customers should largely draw upon the same techniques for presenting any proposal to stakeholders. However, some specific elements should be considered a fundamental part of that proposal. Here are some typical areas to focus on:

Topic

Detail

Define purpose and goals

Articulate the objectives of the CoE, such as driving continuous improvement, sharing best practices, fostering collaboration, and accelerating DevOps adoption across the organization.

Build a business case

Create a compelling business case that demonstrates the benefits of a CoE, including potential cost savings, improved operational efficiency, faster time to market, and enhanced customer satisfaction. Showcase industry examples and relevant success stories.

Identify key stakeholders

Identify and engage key stakeholders, such as senior management, development, and operations teams. Involve them in the decision-making process and the subsequent establishment of the CoE.

Propose the CoE structure

Propose a structure for the CoE, including roles, responsibilities, and reporting lines. Estimate the budget and resources required to set up and maintain the CoE. Positions may include DevOps coaches, product owners, and continuous improvement specialists.

Develop a roadmap

Outline a roadmap for implementing the CoE, including milestones, timelines, and key performance indicators (KPIs). Provide a clear plan for leadership to follow and monitor progress.

Plan for change management

Recognize that implementing a CoE may involve significant cultural and organizational changes. Present a change management strategy that addresses potential resistance, communication, and training needs.

Foster collaboration

Emphasize the importance of cross-functional collaboration and knowledge sharing between teams. Propose tools and platforms that facilitate communication and collaboration, such as chat platforms, wikis, or video conferencing systems.

Pilot and iterate

Propose starting with a pilot program involving one or more teams to test and refine the CoE approach. Enable the organization to learn from the pilot, adjust, and gradually scale up the CoE as part of the wider DevOps adoption.

Regularly report progress

Ensure that the progress of the CoE is regularly reported to leadership, including successes, challenges, and learnings. Maintain support and commitment from senior management through transparency.

Demonstrate ongoing value

Continually highlight the positive impact of the CoE on the organization, including quantifiable improvements in efficiency, quality, and innovation. Maintain and grow support for the CoE and its role in the broader DevOps adoption.

Table 2.1 – Elements to consider in a proposal

Overcoming resistance and hesitation

There are several common reasons why people might initially resist the idea of implementing DevOps in their organization, believing that “it’s nice, but it can’t be done here.” Let’s address some of these reasons and provide counterarguments to help dispel these concerns:

Area

Resistance

Counterargument

Organizational structure and culture

The existing organizational structure and culture promote siloed teams and discourage collaboration

DevOps is an opportunity to break down silos and foster collaboration. Start with small changes, such as creating cross-functional teams, and gradually scale up DevOps initiatives as the organization adapts to the new approach.

Lack of skills and expertise

Team members lack the skills and knowledge to implement DevOps practices and tools

Invest in training and upskilling team members and consider hiring or partnering with experts to help guide your DevOps transformation. Continuous learning is a core principle of DevOps, so developing these skills should be viewed as an ongoing process.

Limited resources and budget

There is no budget or resources to invest in new tools, technologies, and training for a DevOps transformation

DevOps can help increase efficiency and reduce costs in the long run. Start small by leveraging existing tools and resources, and gradually expand your DevOps capabilities as you demonstrate ROI and gain organizational buy-in.

Fear of failure and disruption

Changing existing processes could lead to disruptions and negatively impact current projects

DevOps is about continuous improvement and learning from failure. Begin with small, low-risk projects to minimize potential disruptions and use the lessons learned to refine your approach before tackling larger initiatives.

Legacy systems and technical debt

Existing infrastructure and legacy systems make it difficult to adopt modern DevOps practices and tools

DevOps can help address technical debt and modernize legacy systems by promoting incremental improvements and fostering a culture of innovation. Prioritize the most critical aspects of your infrastructure and develop a roadmap for introducing DevOps practices.

Lack of management support

Management does not see the value in DevOps or is unwilling to invest in the necessary changes

Build a strong business case for DevOps by highlighting its potential benefits. Share success stories and best practices from other organizations and consider running a pilot project to demonstrate the value of DevOps firsthand.

Regulatory and compliance concerns

Adopting DevOps practices may conflict with compliance requirements in heavily regulated industries

DevOps can improve compliance by automating processes, ensuring consistency, and providing better visibility. Collaborate with your compliance and security teams to ensure that your DevOps practices align with industry regulations and organizational policies.

Table 2.2 – Reasons and counterarguments to dispel concerns

By addressing these common concerns and demonstrating the potential benefits of adopting DevOps, you can help overcome resistance and encourage stakeholders to embrace this transformative approach.

Summary

There is an often (mis)quoted saying, “Culture eats strategy for breakfast,” and seldom has this been more pertinent than in the world of DevOps. No matter how well crafted your strategy for adopting DevOps may be, it will not succeed if your team is not on board with the culture and mindset required. By promoting the advantages of a DevOps process and ensuring that the entire team works together to this model, with strong communication along the way, you have laid the foundation for a successful Salesforce DevOps transformation and can now build upon it with the tools and techniques we’ll explore in the next part of this book. In the next two chapters, we’ll first look at the essential role that testing plays across your DevOps life cycle, before looking at an example workflow that takes these elements into account with a typical SFDX and Git workflow.

Culture eats strategy for breakfast – or does it?

The quote is attributed to renowned management expert, Peter Drucker. While this version remains in popular use and demonstrates our point here, Drucker’s original quote was “Culture – no matter how defined – is singularly persistent.”

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Learn how to build a DevOps culture to mitigate project risks and boost return on investment (ROI)
  • Delve into the principles of DevOps and how to apply them in Salesforce for maximum efficiency
  • Explore Salesforce DevOps tools, with examples and strategies for building a robust DevOps stack
  • Purchase of the print or Kindle book includes a free PDF eBook

Description

Rob Cowell is a Salesforce DevOps Advocate with extensive experience as a Salesforce Developer and Architect, guiding best practices for Salesforce DevOps. Lars Malmqvist, a 32x certified Salesforce CTA, has 15 years of experience building advanced Salesforce solutions and is the author of two books, Architecting AI Solutions on Salesforce and Salesforce Anti-Patterns. As the Salesforce Platform evolves, architects face increasing demand for advanced solutions. This book serves as your definitive guide to mastering effective DevOps practices crucial for successful Salesforce projects. Beginning with cultivating a DevOps mindset focused on collaboration and communication, it emphasizes governance, visibility, and accountability. You'll delve into tools and techniques, leveraging the robust capabilities of SFDX to craft your strategy efficiently. This book stands out for its practical approach to Salesforce packaging and CI/CD stack creation, guiding you to build a seamless automated change delivery system with freely available software. It addresses critical operational concerns such as ticket management, backups, change monitoring, and data seeding. In the final chapters, you'll discover third-party solutions to expedite your Salesforce DevOps journey, empowering you to deliver sophisticated and efficient projects.

What you will learn

  • Grasp the fundamentals of integrating a DevOps process into Salesforce project delivery
  • Master the skill of communicating the benefits of Salesforce DevOps to stakeholders
  • Recognize the significance of fostering a DevOps culture and its impact on Salesforce projects
  • Understand the role of metrics in DevOps architecture within Salesforce environments
  • Gain insights into the components comprising a Salesforce DevOps toolchain
  • Discover strategies for maintaining a healthy Salesforce org with a variety of supporting DevOps tools

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Jan 31, 2024
Length 260 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781837636051
Concepts :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon AI Assistant (beta) to help accelerate your learning
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want

Product Details

Publication date : Jan 31, 2024
Length 260 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781837636051
Concepts :

Packt Subscriptions

See our plans and pricing
Modal Close icon
£16.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
£169.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just £5 each
Feature tick icon Exclusive print discounts
£234.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just £5 each
Feature tick icon Exclusive print discounts

Table of Contents

20 Chapters
Preface Chevron down icon Chevron up icon
1. Chapter 1: A Brief History of Deploying Salesforce Changes Chevron down icon Chevron up icon
2. Chapter 2: Developing a DevOps Culture Chevron down icon Chevron up icon
3. Chapter 3: The Value of Source Control Chevron down icon Chevron up icon
4. Chapter 4: Testing Your Changes Chevron down icon Chevron up icon
5. Chapter 5: Day-to-Day Delivery with SFDX Chevron down icon Chevron up icon
6. Chapter 6: Exploring Packaging Chevron down icon Chevron up icon
7. Chapter 7: CI/CD Automation Chevron down icon Chevron up icon
8. Chapter 8: Ticketing Systems Chevron down icon Chevron up icon
9. Chapter 9: Backing Up Data and Metadata Chevron down icon Chevron up icon
10. Chapter 10: Monitoring for Changes Chevron down icon Chevron up icon
11. Chapter 11: Data Seeding Your Development Environments Chevron down icon Chevron up icon
12. Chapter 12: Salesforce DevOps Tools – Gearset Chevron down icon Chevron up icon
13. Chapter 13: Copado Chevron down icon Chevron up icon
14. Chapter 14: Salesforce DevOps Tools – Flosum Chevron down icon Chevron up icon
15. Chapter 15: AutoRABIT Chevron down icon Chevron up icon
16. Chapter 16: Other Salesforce DevOps Tools Chevron down icon Chevron up icon
17. Chapter 17: Conclusion Chevron down icon Chevron up icon
18. Index Chevron down icon Chevron up icon
19. Other Books You May Enjoy Chevron down icon Chevron up icon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see www.packtpub.com/support and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to www.packtpub.com/account
  • To contact us directly if a problem is not resolved, use www.packtpub.com/contact-us
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.