Get Started with DevOps
After completing this unit, you’ll be able to:
- Explain how DevOps balances innovation and trust.
- Define the “Three Ways” of DevOps.
- Summarize the research on how DevOps helps teams and companies.
- Explain how DevOps on Salesforce differs from other platforms.
Dev vs. Ops, Innovation vs. Trust
To understand the term DevOps you need to think about how software was traditionally built and run.
Organizations need to innovate and develop new functionality for their customers and employees. To do this, they build and customize applications. This is the role of the development team (Dev).
Those same organizations also need existing systems to be stable, reliable, and secure. This is the role of the operations team (Ops), which can consist of system admins, database admins, website admins, and so on. Their main job is to make sure servers are up and running, service level agreements are being met, and the application is performing as expected.
Working with a cloud platform like Salesforce makes it a lot simpler to build applications. You don’t need an operations team to keep Salesforce applications running, because Salesforce takes care of that for you. But the principles of DevOps are still critical for building on the Salesforce platform.
There’s a natural tension between the need for innovation (change) and the need for trust (stability). Developers need to keep changing the system, while the operations team needs the system to remain stable so they can optimize performance and reduce the risk that change brings.
Historically, in large organizations, Dev and Ops teams had little encouragement to collaborate. The end goal for both teams is customer satisfaction, but specific goals for Dev teams include quickly delivering features and bug fixes, whereas an Ops goal might be to maintain 99.99% server up-times. These goals can conflict, leading to inefficiency and finger pointing when things go wrong. This is often described as “working in silos.”
Breaking Down Silos
DevOps emerged as a way to replace conflict with cooperation between the Dev and IT operations teams. But everyone who works together to deliver an app—business analysts, testers, security specialists, and release managers—all need to work together to build trust while delivering innovation.
The tools and techniques of DevOps help teams collaborate more smoothly as they work toward the shared goal of benefitting end users.
Three Ways of DevOps
Delivering an application is only the beginning. Once the app is running in production, you need to make sure it’s working and gather feedback so you can improve it. In The DevOps Handbook, Gene Kim and co-authors describe “Three Ways” of DevOps: flow, feedback, and continuous improvement. Flow refers to the left-to-right movement of changes from development to production. The goal is delivering value to end users with increasing speed and regularity, working toward a steady flow. This culminates in the practice of continuous delivery, explained later in this module.
But we can’t make changes blindly. As we move faster, we need to gather feedback in the form of development metrics, production monitoring, and end-user feedback. This is the right-to-left movement of feedback back to development.
Feedback is not just information; it’s food for learning. Just like learning, DevOps is not a journey you ever finish. The Third Way is continuous improvement, striving to always improve not only our work but also the way we work.
Development has sometimes been compared to an assembly line, beginning with development and ending in production. But DevOps is better illustrated with a circle or infinity loop, to show that it’s an ongoing process.
Focusing on the Customer
The purpose of every job is to deliver value to some customer, whether that’s a person who pays for a service, someone in the same organization, or someone who benefits from government or charitable work.
It’s important to understand the value that our work delivers, so we can focus on activities that bring value and avoid things that don’t.
Imagine that it takes you one hour to build a great new feature. Clearly, that hour brings value. But imagine that your team only releases once per week, so customers wait a week for the new feature after you build it. That waiting time doesn’t bring any value to the customer. If you can reduce waiting time, your customer benefits.
The modern world has gotten faster, with changes designed to bring benefit to people more quickly and more efficiently. For example, changes in manufacturing over the last century reduced the number of non-value adding steps in a process, and optimized for quick delivery.
DevOps aims to bring similar benefits to the process of developing IT applications. Just like faster searching, communication, and shipping have transformed our world, DevOps focuses on closing the gap between creative people and those who can benefit from their work.
The Research on DevOps
Not only is DevOps a great idea, there’s research to back up its effectiveness. The Accelerate State of DevOps Report is the largest and longest-running research of its kind, and provides independent scientific evidence of the effectiveness of the practices described here.
The State of DevOps Report points to four key metrics to measure the effectiveness of your development process.
- Lead time: Time to deliver completed work to end users
- Deployment frequency: How often you update production
- Change fail percentage: How often updates negatively impact end users
- Time to restore: How quickly you can recover from a failure
The first two measure your speed of innovation, and the last two measure the degree of reliability you provide. Remember, innovation and reliability are both goals of DevOps.
The State of DevOps Report found that some organizations performed far better than others on all four metrics. The authors categorized respondents into elite, high, medium, and low performers. Elite performers had 106x faster lead time than low performers, deployed 208x more frequently, had 7x lower change failure rate, and 2,605x faster time to restore!
Importantly, elite and high performers were both faster and more stable, and low performers had both low rates of innovation and high rates of failures. Your ability to innovate quickly and your ability to do so safely are related, just as better brakes help a race car safely go faster.
Performance on these four key metrics is called “software delivery performance.” This performance doesn’t just impact the IT department, it has an impact on the whole organization. Organizations with elite software delivery performance are twice as likely to meet their overall organizational goals, both commercial and noncommercial.
Copado conducted a similar survey called the State of Salesforce DevOps Report. For organizations with more than 25 admins or developers contributing to Salesforce customizations, the same trend appeared: Teams that released Salesforce innovations more quickly and reliably performed better as a company.
Why do DevOps practices have such a big impact? Your development team may be only a small part of the overall organization, but it has an outsized impact. Whether you’re building applications for the public, or configuring Salesforce for your company’s employees, you’re helping the whole organization succeed.
Research in Copado’s State of Salesforce DevOps Report also indicated that teams struggle to keep performing at a high level as they grow. Many organizations now have dozens or even hundreds of Salesforce developers and admins. DevOps practices like version control, automated deployments, and modular architecture help teams to coordinate and maintain high performance as they grow. To scale effectively, the practices of DevOps are essential.
If better software delivery can help improve company performance, what practices lead to better software delivery performance? In the next units, you learn how practices such as version control and continuous delivery help improve delivery performance.
How Salesforce DevOps Is Different
The things that make Salesforce easier to work with than traditional IT systems also make DevOps for Salesforce a little bit different from other platforms. It requires a special approach.
Traditional IT systems run on infrastructure such as servers, storage, and networking. Developing more sophisticated tools and practices to operate this infrastructure is the Ops half of DevOps. As a SaaS system, Salesforce manages this infrastructure for you, so DevOps tools and techniques that are focused on infrastructure don’t add value to what Salesforce already provides.
And because Salesforce is also a low-code platform, where the majority of functionality can be configured without code, you don’t need DevOps tools that are specifically designed for traditional code-heavy development.
Many people who build without code on Salesforce aren’t professional developers. Some are business users who combine their subject matter expertise with Salesforce skills to customize Salesforce for their teams. These users may be less comfortable with command-line scripting and tools like Git that enable DevOps for other platforms.
So how should we approach DevOps for Salesforce? The underlying principles are absolutely still relevant to Salesforce; they just need to be translated. You also need tools designed specifically to work with Salesforce.
Copado is an AppExchange package that helps you implement DevOps for Salesforce. Copado lets you manage the entire planning, development, and delivery lifecycle from within Salesforce. Copado empowers admins, developers, and architects with a shared platform to plan, build, test, deploy, and monitor changes across teams. Copado DevOps 360 is an analytics package that gives executives and team leaders even deeper insight and governance to track progress, align teams, and enable continuous transformation and improvement.
In the rest of this module, you learn how core DevOps concepts translate to Salesforce, and how you can use them to deliver innovation more quickly and reliably than ever before.