DevOps for Salesforce: CI/CD Challenges
CI creates a constant risk of software failure because teams working on one part of the system can make changes to shared components that can cause other teams’ code to fail. Automated testing provides a layer of protection by allowing functionality to be checked and rechecked thousands of times with minimal human intervention. Creating automated tests requires more effort than running a manual test, but the cost of re-running each test becomes negligible. Thereby, automated testing is a perfect solution for high-velocity teams that need fast, continuous ways to ensure they don’t regress as they develop new capabilities.
Continuous delivery (CD) is a separate practice that is often mentioned in the same breath as CI. Continuous delivery was popularized by the 2010 book of the same name by Jez Humble and Dave Farley. The CD practice extends the idea of CI by aiming to regularly deploy code to production in small batches; ideally at least daily. While CI deals with the development risks in parallel, CD deals with the risks of delaying feedback from end users.
The software is designed to solve specific problems. But every attempted solution by the developers is a hypothesis that needs to be tested and confirmed. Only people who experience this problem can tell developers if these solutions are sufficient. So developers need to get quick feedback from end users to have confidence in what they’ve built. Teams that neglect this practice operate on assumptions and optimism; the longer they delay delivery, the greater the risks of these assumptions. Poor adoption and user experience are to be expected when teams don’t practice continuous delivery.
CI creates additional pressure to test quickly, CD increases this pressure significantly. Delivering small batches of changes reduces the risk of each change and makes them faster and easier to undo. Corn by definition, we change production systems that may be used by thousands or millions of people every day. A failure caused by CI can waste hours of a developer’s time and delay the delivery of a change. But a failure caused by one CD can prevent thousands of people from doing their jobs, corrupt production data, expose security vulnerabilities and worse.
When developers bring their work into CI, the goal is to run a quick set of tests that confirm nothing major has broken. But work delivered to production must go through a battery of comprehensive tests to ensure that it meets all functional and structural requirements. In a waterfall-type project, pre-release testing can involve dozens of testers working for months. In continuous delivery, teams must be able to run tests at all levels of the system and be confident that no failures have occurred.
Comprehensive testing requires testing the user interface, testing processes spanning multiple systems, loading and confirming data using APIs, testing security, and more. Continuous delivery has pushed the need for automated testing to new levels and led to entirely new approaches like canary deployments. Canary deployments are a form of right-shift testing where a feature is initially delivered to a small subset of end users to check for issues before deploying it. to everybody.