09 Jun Managed Services DevOps Part 2—Planning and Code Build
by Cory Griffin
In many ways, DevOps is a constant, ongoing process. But that doesn’t mean it comes without some advanced planning and preparation. When an organization launches a technical initiative, whether a system enhancement, a bug fix, or a large project, the first step must be to discuss and align on the objectives, timeline, and potential obstacles—all before any code development actually takes place.
Even among those already employing Salesforce DevOps, 43 percent claim to have post-deployment performance problems 15 percent of the time. That may not seem like much, but wouldn’t it be nice if just a little bit of prep work minimized or eliminated that uncertainty altogether? That’s why taking some time to plan and prepare with all affected stakeholders beforehand is worth the extra step. A roadmap and analysis stage helps make sure your projects have the highest chance of success and are executed as seamlessly as possible.
In this blog, we’ll review everything that should happen before development work during the planning phase, some strategies for when the code building phase actually begins, and other ongoing best practices for maintaining a clean, lean, DevOps machine.
The Planning: Everything that happens before dev work
Many steps need to be taken before a code engineer team even begins to build. The organizations with the strongest DevOps are the organizations with resources that understand people, company processes, and true business needs. You want to spend the planning phase achieving widespread alignment on the goals of the DevOps projects. This is done by breaking down technical requests or requirements into their core business objectives and agreeing on a timeline.
– Identify Objectives: A good DevOps team will drill down to the core business objectives by asking the right questions during the planning stage. What this means is that “Requirement Analysis” shouldn’t just be creating a to-do list, but guiding active conversations to identify the desired outcomes and goals. In many cases, the technical requests asked aren’t aligned with the true business needs. That’s why the DevOps team takes time now—at the very start—to ask the right questions regarding existing tech stack, hierarchical organization of the company, department visibility, and processes.
– Determine the Timeline: Once the business objectives are aligned with the technical requirements, capacity planning and a roadmap can be designed. This process will include an analysis of prioritization of requirements/requests, what there is time to do, and how work can be subdivided into phases or sprints to best accomplish the work.
All in all, the planning phase is all about considering the broader organization and the architecture of the technology. DevOps practitioners should be on a mission to find out how those two intersect. Performing in the best interests of the organization is not about doing exactly what the requestor has asked to be done, but ensuring that the solution fits within the entire organization’s business objectives. A team that puts the time in now, in advance, saves countless hours of possibly redundant or unnecessary work later on. Early investment in planning [communication, alignment, and analysis] saves on wasted dollars and effort later on.
The Coding: Strategies for codebase management and configuration
Now that a thorough understanding has been achieved through the planning stage, developers are ready to start building. As part of our Managed Services DevOps practice, we emphasize three key strategies for clean, reliable coding: codebase management, configuration standards, and following org limits.
– Codebase Management: Codebase management is version control for code development. Using GitHub or BitBucket, we establish a code baseline and then document every iteration of code changes. Changes made by developers are merged into the baseline (or branch) where they can be tested and deployed to production as a new version of the software.
– Configuration Standards: Simplus’ coding and configuration standards emphasize that same clarity and enforcement as codebase management. But configuration standards not only apply to our code documentation but anything done in Salesforce. New fields, objects, or workflows are all clearly documented so that an admin can look back later on and understand 1) why the change was made and 2) what else that change may affect.
– Org Limits: Org limits or object limits are often brought up during planning, but they require close attention throughout the project and especially during code build. A good consultant will be following DevOps best practices and is going to clearly understand what these limits are, how they’ll be affected by changes or new solutions, and when to use alternatives to avoid maxing out these limits.
The Constants: Environment management and continuous integration
Finally, there are two best practices that we at Simplus adhere to throughout DevOps projects: environment management and continuous integration. Let’s define those and explain why these are so important to the overall success of your DevOps goals.
Development environment management:
Development environment management is maintaining control over the many different Salesforce development sandboxes your org may have. Having multiple environments is helpful to allow developers to build on their own, create proof of concepts, or just to have a playground for trying out new ideas. There are also more controlled environments such as the “full copy sandbox,” a place to house a copy of the production environment for testing and deploying new features. Having (and more importantly, sticking to) an environment management plan helps to keep these various environments secure and clean, ultimately ensuring that integrated systems aren’t affected during build, testing, and so on. Everyone should understand what environments are used by who, for what, and at what point in the development lifecycle a solution should move from one sandbox/environment to another. Other benefits to development environment management include…
– Reduced deployment issues and bugs
– Support for sprint planning and deployment windows
– Ability to progress and move forward quickly
Another best practice utilized by Simplus DevOps is continuous integration. Continuous integration means pushing little bits of code into the full code base on a regular basis. Rather than pushing all proposed and developed code at once, we push one bit of code after another, bit by bit. This allows us to see how each section of code affects the live testing environment and, if an issue arises, we can quickly identify the source of the issue since we only pushed one bit of code. If all code is pushed at once, multiple issues may arise, and it’s a lot harder to identify what issues are due to which sections of code. With continuous integration, however, we can identify problems as they arise and fix them immediately. Lots of small changes done one by one makes for a faster, cleaner solution than one large set of changes.
And there you have it: the planning and code build stages to DevOps projects. With a little bit of extra time up front and careful strategies for maintaining a clean code development, you can set up your DevOps initiative for long-lasting success.
Overwhelmed by the planning and code build requirements? You can trust the proven Managed Services experts right here at Simplus to handle your DevOps coding with years of experience and skill. Reach out today to learn more.
Now the next phase is testing and release. My colleague Tara Heavner will tackle these next steps in the DevOps journey with next week’s installment.
Cory is a delivery manager in Simplus’ Managed Services practice. With over ten years of experience on the Salesforce platform, he has experience in multiple roles in the delivery lifecycle, including architect, consultant, admin, and project manager. Holding 11 active salesforce certifications, Cory is a business-driven resource with the technical acumen to support practical, results-driven solutions.