This article is based on reporting originally published on InformationWeek. Direct quotes are attributed to Jeff Battles, Senior Director of Product Management at BlueWave Solar, and Andrew Leigh, Senior Vice President of Marketing and Alliances at Copado.
Background: BlueWave Solar and Its Software Challenge
BlueWave Solar is a community solar developer and servicer that acquires land, builds solar farms, and manages subscriptions for customers who would not otherwise have direct access to solar power. At the time of this case study, the company served more than 3,000 subscribers across Massachusetts and New York, drawing on approximately 135 megawatts of solar capacity.
Core business functions — billing, customer acquisition, customer service, and subscription management — all ran on the Salesforce platform. According to Jeff Battles, Senior Director of Product Management, Salesforce enabled BlueWave to iterate and grow quickly in its early stages. However, as the organization matured, gaps in the development and deployment workflow began to create friction.
The Problem: Monthly Releases and Unmanaged Configuration Changes
Before adopting a dedicated DevOps toolchain, BlueWave released software on a monthly cadence. Each release involved a significant accumulation of changes, a complex deployment event, and reactive troubleshooting afterward.
“There was a lot of complexity going into our production environment at once.”
— Jeff Battles, Senior Director of Product Management, BlueWave Solar
A key pain point was the split between code and configuration. BlueWave tracked source code changes in GitHub, but Salesforce configuration and low-code development changes were not managed there. This created blind spots: configuration drift between developer sandboxes was difficult to detect, and there was little visibility into what was changing on the configuration side of the platform.
The team also lacked a clear process for managing development environments across team members, making it harder to collaborate without overwriting each other’s work.
Evaluating DevOps Tooling for Salesforce
BlueWave evaluated several Salesforce DevOps platforms before making a decision. Alternatives considered included Flosum and Gearset. The team ultimately selected Copado for several reasons:
- Native Salesforce integration: Copado runs inside the Salesforce platform itself, giving it a familiar interface and reducing the overhead of learning a separate toolchain.
- GitHub compatibility: Copado integrated with BlueWave’s existing GitHub repositories, extending version control to cover configuration changes alongside custom code.
- Sandbox back-deployment: The platform allowed developers to back-deploy one developer’s changes into another developer’s sandbox, reducing merge conflicts and environment drift.
- Support for citizen development: Copado’s workflow made it practical for non-technical staff trained on Salesforce to make low-code or no-code changes, with the dedicated tech team reviewing and promoting those changes to production.
What Changed After Adopting Copado
BlueWave adopted Copado in late 2018. The results reported by Battles were significant:
- Deployment frequency: Releases moved from monthly to several times per day.
- Change size: Smaller, incremental changes replaced large, risky batch releases.
- Feedback loops: Faster deployments meant issues were identified and resolved much sooner.
- Citizen development: Business-side staff could contribute changes within the Salesforce environment, freeing the core engineering team to focus on higher-complexity work.
The shift toward smaller, more frequent deployments is consistent with well-established DevOps principles. Reducing batch size lowers deployment risk, shortens the feedback loop, and makes rollback or remediation simpler when issues do arise.
Citizen Development and the Role of Low-Code in DevOps
One notable outcome of BlueWave’s adoption of Copado was unlocking a more structured citizen development workflow. Citizen developers are employees outside the core IT organization who build or modify applications — often because they are closest to the business problem being solved.
“Oftentimes, those people are closer to the business problem that they are facing.”
— Jeff Battles, Senior Director of Product Management, BlueWave Solar
By routing citizen developer changes through a governed review and deployment process, BlueWave captured the speed and domain knowledge of business users while maintaining the oversight of the engineering team. This is an increasingly important pattern as low-code platforms become more capable and more widely adopted within enterprises.
Broader Context: DevOps for Salesforce Ecosystems
Andrew Leigh, Senior Vice President of Marketing and Alliances at Copado, noted that while Salesforce is a widely used platform for digital transformation, purpose-built DevOps tooling for it was slow to emerge. Standard software engineering DevOps tools are often designed around code repositories and build pipelines that do not map neatly onto Salesforce’s metadata-driven configuration model.
Leigh identified visibility and governance as growing priorities for organizations undertaking large-scale digital transformation — not just automation of CI/CD pipelines. As transformations grow in scope, leadership needs insight into what is changing, who is making changes, and whether those changes align with broader organizational goals.
“Technology itself is not enough.”
— Andrew Leigh, SVP Marketing and Alliances, Copado
Key Takeaways for DevOps Teams on Salesforce
BlueWave Solar’s experience surfaces several practical lessons for engineering and platform teams managing Salesforce-based applications:
- Treat configuration as code. Salesforce configuration changes carry the same risk as code changes. Version-controlling them in GitHub (or equivalent) gives you audit trails, rollback capability, and conflict detection.
- Reduce deployment batch size. Monthly releases accumulate risk. Moving to smaller, more frequent deployments reduces the blast radius of any single change and accelerates feedback.
- Manage sandbox environments deliberately. Without tooling to synchronize developer sandboxes, environment drift becomes a hidden source of deployment failures.
- Build governance into citizen development workflows. Allowing business users to contribute changes is valuable, but only with a review and promotion process that ensures quality and consistency.
- Match your DevOps toolchain to your platform. Generic CI/CD tools may not handle Salesforce metadata well. Evaluating platform-native or platform-aware tools can reduce integration friction significantly.
BlueWave Solar’s transition from monthly to multiple-daily deployments is a concrete illustration of how adopting DevOps practices — even on a platform like Salesforce that is often treated as configuration-only — can produce measurable improvements in delivery speed and software quality.