91��ɫ

DevOps was born out of lean operations in manufacturing. Just like manufacturers benefit from assembly lines—specialists efficiently completing a piece of work and passing it along to the next specialist—software development benefits from small batch sizes. When a developer completes a user story and hands it off to QA, they allow the development lifecycle to operate in parallel, creating a constant flow of work rather than a build and wait model.

Moreover, small batches enable a wealth of benefits beyond continuous workflow: low-risk releases, quicker time to feedback, features delivered sooner, etc.
Despite these benefits and the widespread adoption of CI/CD and version control, many companies still struggle to truly achieve agile processes. Why is this? One big reason is that companies are still deploying big batches, preventing teams from getting the full value out of DevOps.

In this article, we’ll take a look at the business benefits of small batches and discuss how you can enable lean methods in your Salesforce development processes.

The Cost of Large Batch Deployment

A batch refers to work (or grouping of work) that is deployed upstream to a new environment and/or to the next step of the development process. The efficiency of batch deployment has a significant impact on both productivity and innovation. Large batch sizes tend to increase the complexity of testing and release, elongating the time to value

The delay in value generation is tied to two primary costs in the development process: transaction costs and holding costs.

• Transaction cost is the cost of deploying your software into production. It includes the labor required to move the developed feature through the system, integration, and user acceptance testing.��
• Holding cost is the cost of the feature deployment delay to your organization. Until the end-user has access to the new feature and can use it, the feature cannot generate value or build ROI. In addition to the lag in ROI, holding also requires maintenance and tracking, adding more costs to your project.

If you expand the time between releases, your team develops more features, which are then placed in the queue for testing and deployment. Every incremental feature increases the complexity of the release. Essentially, the larger the batch the longer it takes to test and release, increasing time spent packaging deployments and project managing. Increasing both the cost to build (transaction cost) and delaying it the time to business value (holding cost).

Transaction costs aren’t recoverable, so the more you increase them, the lower your long-term ROI. So when large batches increase both transaction and holding costs, they can have a big impact on the ultimate ROI of the features you deliver.

The Benefits of Deploying Small Batches

While transaction costs are not recoverable from ROI, you can reduce them with small batches. If you need less resources to manage a feature release, you both accelerate it’s time to value and decrease transaction costs. Small batches also help reduce the variability, risk, and overhead. Let’s look at how shifting to small batches impacts your entire software delivery lifecycle to unlock those savings.��

Increase the Future Value Payment Schedule

The future value payment schedule refers to the time it takes for a feature to build ROI after deployment. When you deploy small batches more frequently, the feature goes into use and begins to generate value earlier than if all the features were kept until development was complete and deployed simultaneously.��

Your future value payment schedule grows because you reduce the additional project costs from tracking and queuing features that are ready for deployment. Instead, you begin to build ROI quickly for the entire project by starting to incrementally generate ROI from each feature deployed.

Deploy a feature, and it begins . Each feature after that adds more. If you wait until all components are ready to deploy, you lose any revenue that could have been generated during production.��

Reduce Lead Time and Increase Deployment Frequency

The shorter cycle times and shorter lead times allowed by smaller code changes mean features make it into production faster. You reduce variability in process flow with the predictability of small batch sizes.

Like the assembly line we mentioned earlier, small-batch production enables several specialists to work simultaneously. One specialist builds a small batch of work, sends it to the next specialist for testing, and so on. Each specialist takes care of a specific step in the process, so when you deploy small batches, you keep specialists working in parallel rather than in one long line (waterfall).

Reduce Variability in Your Delivery Flow

Large batches lead to testing and deployment queues, which causes release times to vary. With small batches, both the queue and the bottlenecks shrink. And when variability is reduced, you can plan and improve your delivery processes better, allowing you to build trust with the business.

Get Better Feedback Faster

Without feedback, you may make incorrect assumptions that change hundreds of future decisions. Rework due to delayed feedback is expensive and avoidable. With faster feedback, you may even discontinue a project before it becomes "too big to fail."

Faster feedback is possible with small-batch work because each feature is released upon completion and placed into production. The earlier it goes into production, the faster the customer can use the new feature and let you know what may need changing.

Also, with smaller deployments, the customer can concentrate on providing feedback for a single change as opposed to multiple changes.

Reduce Risk

A small batch with a short cycle time exposes your project to a lower risk of technology or requirement changes. If you have a large, complex feature to release, break it into smaller batches. This will allow your QA team to more effectively test dependencies and allow you to gather feedback on functionality more quickly. By reducing errors released and gathering feedback fast, you’ll increase the adoption—helping further increase ROI.

Reduce Overhead

The larger the batch, the higher the complexity—and higher risk for manual merge and testing errors. When you reduce manual work through continuous delivery, you also reduce human error. Your team spends less time deploying, less time doing rework, and more tine building profit-driving capabilities.

Enabling Small Batches for Salesforce Development

For some, DevOps has become synonymous with technologies like version control systems (git) and continuous integration systems (Jenkins), but true DevOps success is rooted in both process and technology. Just like manufacturing companies shifted their operations to assembly lines, software developers must also shift how they operate in order to get the most out of DevOps—and small batches.

The importance of admin-friendly version control

Version control has been core to software development for decades, with most companies leveraging Git repositories. Version control provides a history of changes that contains information essential for debugging and decision making, making both deployment prep and rollbacks more efficient.

Code repositories were built to be used by developers with scripting and command line as key functions used for merging. But if you’re building on a low-code platform like Salesforce, you’ve likely got a team of skilled Admins configuring updates. Salesforce Admins help push out new functionality rapidly, but as your org becomes more complex, managing config and code can be tricky.

That’s where a native platform like 91��ɫ comes in. Admins can click to commit. This allows Admins to quickly adopt DevOps processes without needing to learn how to code. And when your Admins can quickly commit, you’re one step closer to small, continually released batches.��

Integrate early & often

Next, you’ll need continuous integration, which enables teams to work in parallel. This allows your team to work more efficiently. Small batches are essential to getting the most out of CI systems and DevOps. And this is where process and technology start to overlap.��

First, you’ll need to adjust when you merge changes and deploy between sandboxes. It’s best practice to commit each piece of work once it’s completed and ready for testing. Automated unit testing allows developers and Admins to quickly and confidently commit. Teams may need to adjust their processes to support this model. Remember, DevOps is rooted in learning, and your teams will become more confident with frequent merges overtime, eventually making small batches.

Secondly, we’ll address the technology challenges of CI for Salesforce. Because Salesforce uses XML, developers cannot simply merge changes into a git repository. The XML must be packaged, which can be manual, time consuming, and error-prone. 91��ɫ automates packaging and can test for errors prior to merging. This is essential for leveraging small batches on Salesforce. Without automation, most teams will abandon small batches because it’s just too time consuming to deploy early and often.

‍

��

��

��

��