Today’s business users expect the apps they use at work to be updated with bug fixes and new features as frequently as the apps they use on their phones. This has pushed IT organizations to evaluate DevOps as a way of providing secure, fast, test-driven deployment of app updates. However, while there are best practices that IT can follow when applying DevOps to business apps, like Salesforce, there is still a lot of confusion and misunderstanding about the nature of DevOps. After discussing this topic with several of our clients and industry leaders, I thought it would help to review the top 6 DevOps myths that apply to implementations of Salesforce.
Myth #1. Continuous integration and continuous delivery (CI/CD) is only for custom web apps and doesn’t apply to apps like Salesforce, ServiceNow, and Workday.
CI/CD was originally developed by modern operations teams at Software as a Service (SaaS) companies, like Amazon and Netflix, but the concept of CI/CD can apply just as easily to modern software. Users of web apps have become accustomed to SaaS companies rolling out the latest versions of their software quickly and reliably. DevOps offers a way to provide a similarly seamless experience for apps from non-web software providers.
Many cloud software platforms do not provide adequate DevOps tools to help manage customer-specific code and feature developments. This is where AutoRABIT can help. AutoRABIT offers fully integrated software versioning, release management, and test automation, with secure build deployments to production and non-production environments, to help you move quickly to a DevOps culture.
Myth #2. DevOps and continuous delivery are the same.
It’s true that continuous delivery of software does indicate that an organization has established key components of a DevOps culture, but continuous delivery and DevOps are not dependent on one another. They certainly aren’t the same thing.
Myth #3. Continuous delivery means releasing software every five minutes.
This myth centers around the ambiguity of the term “continuous.” Even companies known for their DevOps skills, like Amazon, Netflix, and Google, do not deliver new software versions continuously. These organizations have achieved a level of confidence in their systems and processes that allows them to release new software when required. That may mean releasing new code every two weeks or it may mean releasing several times a day.
Facebook’s engineers are renowned for their “ship often” moto but even this well-known maxim does not indicate a time frame. At any given moment, Facebook engineers can rollout new enhancements or changes, for a variety of reasons. To Facebook, continuous delivery means refusing to roll back production changes, even if a problem is detected. Instead, engineers release a fix as soon as possible. With this approach, the code is continually improving.
Myth #4. Adopting DevOps doesn’t require C-level buy-in.
In their 2015 State of DevOps Report, Puppet Labs found that successful adoption of DevOps requires buy-in from both grassroots and upper management. While a small “skunk works” team can get the DevOps ball rolling and start a cultural shift, eventually you will need the CEO and executives on board, too.
The sooner you can get everyone focusing on the DevOps transformation effort, the better. Navigating the communication channels, paperwork, and red-tape necessary for a meaningful conversation with upper management can be challenging, especially in a large dispersed organization. But it’s not impossible. Wells Fargo, Capital One, Anthem, Disney, and many other large organizations have already adopted DevOps practices and have begun their transformation.
Myth #4. Adopting DevOps doesn’t require C-level buy-in.
Another common myth is that DevOps is not relevant to all organizations. This argument runs counter to the idea of digital transformation that has become a near-universal strategic goal at almost all organizations. Business users, customers, and partners now expect their digital tools to be updated frequently with bug fixes, software updates, and new features. This is the very definition of DevOps, and in fact, DevOps and digital transformation go hand-in-hand.
There is also a belief that DevOps does not provide high quality, secure deliverables. This idea has taken hold because many DevOps tools to-date have been home-grown approaches that required a lot of custom coding and scripting. AutoRABIT provides a fully integrated DevOps platform that enables organizations to implement faster, provide higher quality deliverables, and ensure secure deployments.
Myth #6. What are the key elements of a true DevOps maturity model?
The goal of establishing a DevOps maturity model is to provide a path to seamless integration and continuous delivery. In agile software development methodology, DevOps automation is the key to achieving the best possible software delivery process. However, there are a number of challenges that require programmatic assistance in support of the model.
Generic DevOps tools can provide a foundation for a software delivery process, but they require custom scripting to support integration and ongoing version control and change management. This scripting demands a particular technical skill set and is time-consuming to develop, adding delays and costs to the rollout of DevOps processes. AutoRABIT recently reviewed the build versus buy dilemma in an informative webcast that discusses choosing the right path for DevOps automation.
AutoRABIT provides a seamless developer experience to help you mature the software delivery process. It offers fully integrated versioning, release management, test automation, secure code scanning, build integration, and deployment to a variety of cloud solution providers platforms, including Salesforce.