CI/CD Archives

Customers gave Prodly outstanding ratings as a DevOps platform, as well as a CI/CD and cloud migration platform. This resulted in Prodly being named a leader in the mid-market grid for cloud migration and a high performer in more than five categories of the G2 Winter 2023 Reports, including for CI/CD tools for enterprises.

In addition, Prodly DevOps was the Fastest Implementation Enterprise product in the implementation index, meaning that it had the shortest go-live time in its category.

Prodly was also named a momentum leader in the cloud migration solution category.

Superior Ratings for Prodly as a DevOps Platform

As an end-to-end DevOps platform, Prodly DevOps was named a high performer in the DevOps platform category, outperforming Copado in all eight metrics used to measure customer satisfaction. Moreover, Prodly received higher satisfaction ratings than both Copado and Gearset when it comes to our platform meeting requirements.

DevOps platforms ensure organizations’ continuous delivery projects are clearly defined. These projects must also be effectively automated and efficiently manageable within one framework to implement agile work environments in a streamlined manner.

Outstanding Reviews for Prodly for Continuous Integration

As a high performer, the Prodly DevOps suite outperformed Copado in all eight metrics of the continuous integration category. This ranks applications according to their ability to integrate with configuration management solutions, continuous delivery applications, and continuous deployment software.

Notably, more customers were likely to recommend Prodly than Copado. Moreover, more customers agreed our product met their requirements compared to Copado.

Excellent Ratings for Prodly for Continuous Delivery

The Prodly DevOps suite was a high performer in the continuous delivery category, outperforming Copado in all eight metrics. Continuous delivery applications build on the capabilities of continuous integration software up to the point of deployment.

Again, more customers were likely to recommend Prodly than Copado, and more found that our platform meets their requirements when compared to Copado.

Superior Ratings for Prodly for Cloud Migration

Prodly was named a leader in the mid-market grid report for cloud migration, as well as a high performer in the cloud migration category. Cloud migration applications migrate large amounts of contacts, calendars, communication, and other data between cloud repositories or apps. This simplifies the organization, consolidation, and integration of a range of data types.

Prodly DevOps received higher satisfaction ratings than Hubspot Operations Hub in four of the eight categories, including for the likelihood to recommend the product, as well as the solution meeting requirements. In addition, it received higher ratings than Salesforce Connect in all eight categories

The Prodly suite of products is a comprehensive, end-to-end DevOps platform that enables change management in Salesforce without the need for programmatic knowledge. With solutions for work management, sandbox management, sandbox seeding, CPQ deployments, regression testing, and SOX compliance, it provides companies with the “clicks, not code” tools they need to accelerate innovation, bring new apps to their users faster, and drive more value to their customers.

Request a demo of Prodly in action!

It’s critical for Salesforce teams to have a best-in-class release management strategy to ensure they can deploy changes to production accurately, effectively, and without any bugs. In this blog, we discuss how to build a best-in-class release management strategy in three phases. You’ll advance from a basic strategy with manual deployments to an intermediate one with CI/CD and ultimately to an expert level with automation.

Phase I: Basic Release Management Strategy

A basic release management strategy defines when and where changes are promoted from one Salesforce org to another. Release management is the practice of packaging tested and approved changes and then deploying them to production.

The principles of a basic release management strategy are:

Set a release schedule and build packaged releases of verified changes.
Establish roles and responsibilities for production releases.
Establish testing and approval standards.

Because this phase is foundational to building a best-in-class release management strategy, we’ll take a closer look at the components you need for it.

Verified Changes

A release consists of verified changes made by Salesforce admins, developers, or contractors. Business users request these changes by means of work items. When combined, the changes in a release deliver an enhancement, new feature, or bug fix.

The most fundamental principle of release management is that the changes must be verified. So this means you must have a full understanding of what has changed and why—and the certainty that the change works as desired.

To verify changes, you need to have:

Well-defined and documented work items
Test plans to ensure the changes accomplish their intended purpose
Regression test plans to ensure the changes don’t break existing functionality
Fully-documented configuration changes

Note that there’s a lot of emphasis on documentation. This rigor is standard in software development, but generally lacking in Salesforce practice.

To see differences between orgs, it can be helpful to use a tool like Prodly DevOps. You can see everything that’s different in the development environment compared to the destination environment and generate documentation accordingly. That way, pieces of the release won’t be missed. In addition, you can easily identify which changes work and which didn’t pass testing.

Next, when you have verified the changes, you can package them together for a release.

The Packaged Release Deployment Flow

Before deploying any changes, you need to define your packaged release deployment flow. In other words, you must decide how to move the changes through the various stages of development to production.

Also, determine how you’ll sync new work back down to lower-level environments. This gives your developers and admins a clear understanding of the impact of their work based on the ever-evolving state of production. In addition, it helps prevent the, “This worked in my Dev org, but it doesn’t work in UAT” conversation.

Each stage of development should have its own dedicated environment. As a result, it’s best practice to use feature branch orgs, which means using one scratch org or Developer sandbox per feature you’re creating.

Here’s what a basic release pipeline should look like:

Create a Dedicated Hotfix Environment

All new work should go through the defined release path. However, no process is perfect, and occasionally, a bug makes its way into production.

When that happens, you can save yourself a ton of headache by having a clearly defined hotfix strategy. It’s like insurance. You don’t want to realize you’re not covered after you’ve been in a collision.

Create a dedicated hotfix environment where you can isolate the bug, fix it, and then sync it to all the in-flight orgs in your release path. Otherwise, you risk re-introducing the bug in the next release.

Some Salesforce teams use a Full Copy sandbox as their hotfix environment. However, this isn’t necessary. In contrast, with a good seeding strategy, you can recreate the components that matter in a scratch or Dev org and develop a fix there.

Using this strategy, you can build hotfixes without interrupting the rest of your release management flow. You can debug and fix a production problem in a targeted environment and push the components to production in an isolated hotfix release. Then you can share the hotfix to lower environments to ensure you don’t introduce the same bug again.

Phase II: Intermediate Release Management Strategy

After you’ve established all the fundamentals discussed in Phase I, it’s time to move to the intermediate level. The main principles of this phase include:

Align with the “environment per feature” strategy as part of release management.
Establish release paths for long-term and short-term development work.
Start using an integration testing or merge org to package releases.

A Current, Dedicated Environment Per Team Member

At the intermediate level, give every team member their own up-to-date development environments to do their work. This prevents them from overwriting each other’s work and stepping on each other’s toes.

It’s critical to keep the environments up to date with the solid packaged releases you learnt how to make in Phase I. By always providing your team with current development environments, you minimize the chances of errors and bugs.

CI/CD Process

You can now set your first steps on the path towards the continuous integration/continuous delivery (CI/CD) process. Along with setting up the necessary environments and keeping them up to date, you can also establish long-term and short-term development projects.

Because you’re no longer doing all the work in a Full Copy sandbox, you don’t have to wait for long project work to be completed to get smaller enhancements into production. Plus, you don’t have to worry about refreshing your—costly—Full Copies, because you’re performing the major units of work in isolated development environments.

Integration or Merge Environment

At the intermediate level, it’s important to have a dedicated integration or merge environment where you pick up, test, and package the changes created in your development environments.

Now the full value of packaged releases becomes clear. Why? Because you can promote them forward to higher-level environments—UAT, staging—and ultimately, to production. On top of that, you can back feed them into development environments so everyone is up-to-date with the most recent build work.

Phase III: Expert Release Management Strategy

At the expert level, you perform more frequent deployments that you manage more with automation and tools as opposed to manual drudge work.

The essential principles of the expert phase are:

Integrate with source control for the ability to roll back changes to a previous state, as well as for an automatic audit trail.
Package releases in your repository.
Automate the deployments throughout the pipeline to production.

Version Control

Best-in-class organizations have some way to back up their deployment destinations. This allows them to quickly roll back changes if something unexpected happens. Usually, they leverage GitHub, Azure, or some other version control system to version and automatically deploy metadata and configuration data.

Package Releases in Your Repository

When you use a repository for version control, it’s easier to package changes there than in a Salesforce environment. The reason for this is that—assuming you’re using feature branches at this point—it’s easier to manage multiple inputs in a repository than in a Salesforce org.

Automate the Deployments

Instead of performing all the deployments manually, best-in-class organizations automate them with a tool like Prodly DevOps.

Prodly DevOps allows you to automatically deploy all the changes required for a work item at once. That means both data and metadata! You can integrate to a version control system for source control and automatic versioning. Plus, it included prebuilt automations for major Salesforce Clouds that save you tons of time and work!

Continuous Integration

A best-in-class release management strategy involves CI/CD. Continuous integration sends verified packages into your long- and short-term production environments—and you can use automation for this.

Continuous Delivery

Continuous delivery involves moving packages up the pipeline to your production environment. Using a staging environment, you can automatically deploy your packages as often as you like. By appropriately managing and testing the releases, you ensure that the work you push to production will have the desired functionality.

Regression Testing

Best-in-class release management also calls for automated regression testing. Establish your testing plans and execute them automatically to avoid introducing bugs into production. The stronger your test plan is, the more you can rely on automated deployments.

Conclusion

If you adhere to the pointers in this blog, you’ll soon be able to progress from a basic release management strategy to an intermediate one—and eventually to the expert level.

At the expert level, it becomes incredibly important to have the right automation tools. We’ve already briefly discussed the capabilities of Prodly DevOps—but why not see them in action? Click here to schedule a demo!

Tag Archives: CI/CD

Superior Ratings for Prodly in the G2 Winter 2023 Reports