Recently, a Salesforce DevOps professional reached out, seeking best practice guidance on implementing Continuous Integration/Continuous Deployment (CI/CD) with Rootstock ERP. The post sparked a robust discussion, shedding light on some common challenges, particularly in sandbox configurations and data requirements for effective CI/CD setups.

At Rootstock, we understand the complexity of integrating our software into a modern CI/CD pipeline, especially with limitations in sandbox availability and configurations. In this post, we’ll explore the key issues raised in the conversation and offer solutions to ensure smoother operations when working with Rootstock and Salesforce environments.

Key Challenges and Community Feedback

The conversation identified three main hurdles when integrating Rootstock ERP into a CI/CD process:

  1. Sandbox Requirements: The original inquiry noted that Rootstock’s setup seemed to work only on full sandboxes, posing a challenge for customers unable to purchase full sandboxes for each development stage (integration, UAT, pre-production, and production). This limits the CI/CD setup as partial and dev sandboxes might not fully support all Rootstock functionality.
  2. Test Class Requirements: There was a concern that test classes might need `@SeeAllData=true` to work with Rootstock, which is contrary to Salesforce best practices.
  3. Manual Activation Needs: The discussion suggested that activating Rootstock in any org might require manual intervention from Rootstock support, complicating automated deployment workflows.

Community members offered valuable suggestions, such as utilizing scratch orgs instead of developer sandboxes and employing Test Data Factories to create essential data for testing. Notably, scratch orgs provide flexibility for creating customized testing environments, though they have a limited lifespan.

Another approach mentioned was using tools like SFDMU to automate the import of minimal data sets into scratch orgs, making it easier to simulate the full sandbox environment without the overhead of large data sets.

Rootstock’s Clarification and Recommendations

Rootstock would like to clarify a few key points that are unique to our ERP on the Salesforce Platform:

  1. Working with Dev Sandboxes: Contrary to the initial concern, Rootstock ERP can indeed be configured in developer sandboxes, though there are limitations. While a full sandbox provides a more complete environment with necessary data, development can still proceed in a dev sandbox. However, due to the data volume limitations (200MB), only a subset of data can be used, which may not fully match the configurations in a full sandbox. This makes it essential to conduct more rigorous testing when moving to the full UAT sandbox, where the exact configuration is replicated, to ensure functionality aligns with production standards.
  2. Creating Test Classes Without @SeeAllData=true: Rootstock does not require test classes to have @SeeAllData=true, aligning with Salesforce best practices. Using a Test Data Factory to create the test data records will simplify the creation of test classes to cover custom code.
  3. Rootstock Assistance: Some aspects of Rootstock’s setup, such as the SYCONFIG object, require manual intervention or password access provided by Rootstock staff. For further details or setup assistance, customers should reach out directly to Rootstock Support.

Best Practices for CI/CD with Rootstock ERP

To address these challenges, here are some best practices based on Rootstock’s experience and community feedback:

  1. Scratch Org Snapshots and Minimal Data Sets: Scratch org snapshots, when configured with minimal but relevant data, can serve as effective CI/CD environments. This approach supports quicker development and testing, especially when full sandboxes aren’t an option. For larger projects, partial sandboxes may work for staging and pre-production environments.
  2. Implement a Test Data Factory: Handling test class creation through a Test Data Factory avoids @SeeAllData=true, ensuring tests adhere to Salesforce best practices related to code coverage.
  3. Full Sandbox for Final Validation: While developer and scratch orgs can streamline many development tasks, testing in a full sandbox remains essential for final validation. This ensures that all configurations and dependencies are in place, providing a comprehensive test environment that mimics production.
  4. Setting Expectations for CI/CD with Rootstock ERP: CI/CD in environments that include complex ERP systems like Rootstock require careful planning and sometimes additional resources. Full sandboxes offer the most consistent and accurate test conditions, so we recommend investing in them for large-scale deployments. Rootstock’s support team is available to help set up and maintain necessary configurations, as certain elements may need Rootstock-managed setup for effective deployment.

Conclusion

Integrating CI/CD with Rootstock can present challenges, particularly in environments with limited sandbox resources. However, by leveraging strategies like scratch org snapshots, Test Data Factories, and collaboration with Rootstock’s support team, customers can build effective CI/CD workflows that maintain testing integrity and minimize manual interventions.

Rootstock is deeply committed to partnering with our customers to drive optimized DevOps pipelines and ensure seamless operations. Given the specialized configurations required for integrating CI/CD with Rootstock ERP, collaboration with our team is essential for achieving reliable, efficient deployments. Our experts are ready to provide the guidance and support necessary to navigate these complexities successfully.

To arrange custom support, connect with Rootstock as you implement CI/CD with Rootstock ERP—ensuring your setup meets the high standards your business demands.