.svg){kind=small}
.svg)
.avif)
.avif)
.avif)
拡張性
言語
.svg)
.svg)
I have been an #AwesomeAdmin for about 15 years now.
This means that I eat, sleep and dream about the Salesforce platform and cannot wait to get my hands on the Release Notes every Spring, Summer and Winter to see what’s new (nerd alert!).
In my time as an SI Partner, I have solutioned across many aspects of the platform – Sales Cloud, Service Cloud, Marketing Cloud, Social Customer Service, Field Service, Nonprofits, Healthcare, Wave…whatever our Internal Users or Customers needed, I designed a solution and had a great time doing so.
But I would give anything to get back all of the late nights, weekends and holidays that I spent Deploying all of my #AwesomeAdmin solutions to Internal Users and Customers.
If only I had known about Copado! This is the only end-to-end Release Management Platform, built 100% native on Salesforce, so all of your DevOps Team Members can collaborate in one centralized Platform for all of your Salesforce Projects.
So, to all my dear #AwesomeAdmin Ohana, and as an homage to the legendary David Letterman, I give you my own Top 10 Copado Features for #AwesomeAdmins!
Track in spreadsheets all work that has been completed in our lower-level Dev Sandboxes, what has been promoted/deployed to UAT, SIT or Integration Sandboxes and what has been promoted/deployed to Production.
Copado allows you to define as many Release Pipelines as your business warrants and then all of your Metadata changes are promoted/deployed across environments in the sequence you define.
Maybe you are using standard Salesforce Cases with a User Story record type or maybe you have created a Custom Object to track Requirements. If you have a standard ALM Platform such as Rally, Azure DevOps or JIRA, they are either independent of Salesforce, or you have an AppExchange or custom-built integration.
Copado has taken the industry-standard ALM Tools such as JIRA and Azure DevOps as inspiration for our own User Stories to allow Scrum Masters and PMs the ability to fully document both Functional and Technical Requirements, Acceptance Criteria and common Agile attributes such as Epics, Sprints and Releases in one easy-to-use point-and-click page.
Copado even offers an Unmanaged Package to manage and customize your bi-directional integration with JIRA or Azure DevOps! Copado Change Management Integrations
Using VersionOne, Rally, Agile Accelerator, ScrumDo or TargetProcess? We have uni-directional solutions for those too!
Copado offers a gorgeous Commit Grid that allows you to leverage multi-column filters including:
Manually create your Change Set(s) in every lower-level/Source Environment in your Release Pipeline each time that you need to Promote/Deploy to a higher Environment.
Since Copado creates a unique Feature Branch in Git for each User Story (Copado Branching Strategy), then Copado creates your User Story Feature Branch once and that same Feature Branch is used for every level of Promote/Deploy of the User Story’s Metadata Changes all the way up your Release Pipeline!
The really slick point here too is that Copado enables #AwesomeAdmins to work seamlessly with git right within Copado (and native Salesforce!), by automatically handling all the git operations (checkout, merge, etc.). No worries about Command Line Interfaces for us #AwesomeAdmins – all git operations are managed by Copado behind the scenes and under the hood. Copado’s got your back!
One additional bonus to mention, as you move User Stories through your Release Pipeline, if a particular User Story is not complying with the QA standards or, for some other reason is not ready, you can decouple it from the Release and that User Story’s Feature Branch won’t be merged to the next Upper Environment.
#6 Additional Git Operations
Because Copado leverages Git as our Version Control and single-source of truth for all Metadata Changes, whether Declarative or Code, our Commit Grid also allows these amazing additional Git Operations.
We are not perfect; sometimes, we grab the wrong Apex Class(es), Visualforce Page(s), Page Layout(s) or other Metadata Component(s) in our Change Set(s) today. To correct our mistake natively, we must:
With the Copado Recommit Git Operation, you use the very same awesome Commit Grid functionality to correct your error quickly, recommit/update the User Story Feature Branch, and, IF you really flubbed, you even have the option to Recreate the User Story’s Feature Branch!
Sometimes in new Orgs, but more often in older Orgs, there is Metadata that we just plain need to delete, whether a Custom Field, a Custom Object, a Profile or Permission Set, a Page Layout, etc.
Native Change Sets do not allow Delete of Metadata so, today, I suspect many of you are doing as I once did, spending hours-upon-hours in each individual Environment manually deleting old Components after you have finalized all other Deployments from a lower Environment to an upper Environment
With the Copado Destructive Changes Git Operation, you use the very same awesome Commit Grid functionality to perform Destructive Changes (aka Metadata Deletes) across all of your Environments as the User Story moves through its Release Pipeline! All with Points and Clicks!
The two most frequent Use Cases we run into as #AwesomeAdmins are:
In order to update the upper Environment, as Admins we must rely on #AwesomeAdmin free declarative tools such as Octopus, Config Workbook or PermComparator to document the Profile and/or Permission Set attributes left behind, but, at the end of the day, we are still left to manually replicate our Full Profile and Permission Set changes/additions in the upper Environments
With the Copado Full Profiles and Permission Sets Git Operation, you use the very same awesome Commit Grid functionality to perform a Full Profile and Permission Set Git Commit that will be added to your User Story Feature Branch and will easily Promote/Deploy to each of your upper Environments as the User Story moves through its Release Pipeline! All with Points and Clicks!
One additional bonus, before explaining the Quality Gates below, is that many of these Quality Gate Objects have a Master-Detail Relationship to the User Story and so, as an Admin, you have the ability to leverage features such as native Rollup Summary Fields to drive Salesforce Automation like a Validation Rule that prevents a User Story from being flagged for Promotion until the Rollup Count of Pull Requests with State = ‘closed’ is greater or equal to 1.
Hope that any Apex added or updated in your lower Environments are clean and follow best practices; wait until you attempt to Deploy to Production to see if you actually clear the 75% coverage required to deploy to Production and see if any of your other Metadata Components are impacted.
Out of the box, Copado includes a free PMD Rule Set to identify common coding errors such as Excessive Apex Class Length, Deeply Nested IF Statements, SOQL Queries inside Loops, Missing Apex Test Class Assertions or If…Else Statements without Curly Braces. Copado Administrators can customize this Rule Set, including exclusion of Rules or the addition of your own Custom Rules.
Additionally, Copado also supports Static Code Analysis if your Organization already has the paid CodeScan (aka SonarCube) tool.
Static Code Analysis Settings are assigned to a Release Pipeline and can be run from an individual User Story or from an Org Credential and can also be invoked as a Scheduled Job that runs Weekly or Monthly.
Finally, Copado allows you to set minimum Code Coverage required per Environment and run native Apex Tests from an Individual User Story or an Org Credential; you can even Schedule Apex Tests to run Daily, Weekly or Monthly for an Org Credential.
Please do note: Copado Selenium Testing is an add-on module that requires additional licenses to be purchased beyond core Copado licenses.
Natively, there is no mechanism for Automated Regression Tests. You may have Selenium in place (for example, Browserstack, Sauce Labs, CrossBrowserTesting), but it is most likely independent of Salesforce, unless you have built your own integration.
When you purchase the add-on licenses for Copado Selenium Testing, you will be able to record, update, schedule and run all of your Copado Selenium Test Cases leveraging Copado Selenium Test Suites and Copado Selenium Test Groups to segment your Copado Selenium Test Cases for common Scenarios, Environments or Test Users.
A simple Webhook will allow you to connect the Copado Selenium Recorder directly to your existing Selenium platform (for example, Browserstack, Sauce Labs, CrossBrowserTesting) in order to host the results (logs, screenshots or videos) of each test case execution.
Natively, there is no easy way for Developers to review each other’s code and effectively collaborate nor provide feedback. Your Developers may already be using a Git Repository such as GitHub, GitLab or BitBucket and may be familiar with Pull Requests, but your Admins, PMs/Scrum Masters and QA Resources likely have little familiarity, nor visibility, on this collaboration and feedback.
With Copado, Resources can create a Pull Request directly from any User Story, add collaborative or feedback Comments and save the new Pull Request to the User Story.
Create a manual tracking solution in Excel, Google Docs/Sheets, Quip or SmartSheet to track all User Tests (Smoke Tests) and verbally review/prod Testers to make progress.
Out of the box, Copado has Custom Objects for User Tests (Smoke/Manual Tests) including Test Scripts, Test Script Steps, Test Runs and Test Run Steps (aka Executions).
Because Capodo is built 100% native on Salesforce, you have full native Salesforce capabilities to add additional Automations, for example, you could create a Process Builder on Test Runs to notify the assigned Tester of a new Test Run Assignment via a native Task, Email Alert or Chatter Post!
Please do note: Compliance Hub is an add-on module that requires additional licenses to be purchased beyond core Copado licenses.
Natively in Salesforce, there is no built-in mechanism to monitor Declarative Metadata Changes and ensure that, as an example, an Admin does not grant a sensitive User Permission to Non-System Admin Profiles, or to ensure that an Admin does not inadvertently reduce the complexity of your Salesforce Password Policies, or even to ensure that Declarative Best Practices have been followed, for example, let’s make sure we don’t make a field required, then configure a default value for the same field.
With Copado Compliance Hub, Administrators can configure Compliance Rules, which are Validation Rules against your Metadata Components using a very familiar UI.
Compliance Rules are put into Compliance Rule Groups and a single Compliance Rule Group can be assigned to one or more Environment, then run across an entire Assigned Environment or invoked for Commits and/or Deployments from individual User Stories.
When creating Compliance Rules, the Admin can define whether a Detected Finding Aborts, Alerts but Proceeds, or simply Documents the Detected Finding.
Natively, to manage our Promotions, Deployments and Sandbox Syncs, we must rely
Native Change Sets
With Copado’s Pipeline Manager, the Copado Admin, Release Manager or PM/Scrum Master has a simple visual of all Environments within a particular Pipeline, easily identifying which Environments are ready for forward Promotion and which Environments are ready for Back Promotion – that’s right! No more Sandbox Refreshes!!!
The Release Manager can cherry pick which User Stories to forward Promote or Back Promote and the fields across the top of the User Story Grid are simply a Field Set from the User Story object, so it is 100% Admin-configurable!
Example Forward Promote:
Example Backward Promote:
Yes, it is true! With Copado, we can actually Mass Back Promote from an Upper Environment to all of the Lower Environments that are behind, with a minimum of 3 clicks!
In the Pipeline Manager, just click the Mass Back Promote button to begin:
The minimum 3 clicks a Release Manager needs to make are:
Above, there are actually 39 User Stories that made it to our Integration Sandbox, but have not yet been Back Promoted to any of our Lower Environment Dev Sandboxes. The Release Manager can further filter the list of User Stories, Cherry Pick and even pick-and-choose across the Lower Environments!
Native Process
Keeping our Sandboxes in sync is critical as our DevOps process matures because it helps us ensure that we minimize overlaps or conflicts in our Metadata Changes when we have multiple Developers and Admins working on common areas of our Salesforce Org. As previously mentioned, there are no native tools to help us avoid Metadata Component conflicts, and who among us hasn’t had an Apex Class or Page Layout suddenly, and without warning, change?
With Copado Promotions, we leverage the User Stories’ Git Feature Branch(es) and, entirely behind the scenes, perform a Git Merge against the Destination Sandbox, Developer Org or Production Org’s Git Branch to determine whether or not Conflicts exist before we perform the final Deployment.
Out-of-the-box, Copado has been developed to automatically perform a Git Semantic Merge any time that a Merge Conflict is detected between a User Story Feature Branch and the Git Branch of the Upper Environment (Sandbox, Developer Org or Production) that we are attempting to Promote and Deploy into (in #AwesomeAdmin-speak, this would be an automatic override to the Metadata Component when there are conflicting changes made to the same area in, as an example, an Apex Class, Lightning Component or Page Layout across two different Environments in our Release Pipeline).
The default behavior for Auto-Resolve is that the highest User Story Number (which is actually the Native Name field as an Autonumber) wins when a conflict is detected and that User Story’s changes automatically override the lower User Story Number with the same Metadata Component presenting a conflict.
A Copado Administrator can override this User Story default on a Release Pipeline by following these instructions Override User Story Promotion Merge Order
For each Release Pipeline within Copado, a Copado Administrator can also exclude Metadata Components such as Apex, Aura/Lightning Components and Page Layouts from Auto-Resolve so that you can assign a DevOps Resource(s) to review and correct the Conflict collaboratively.
Exclude from Auto-Resolve is also a configurable Multi-select Picklist, so the Copado Administrator can add Metadata Components to the Multi-select Picklist as your Business Use Cases warrant.
When Metadata Components have been excluded from Auto-resolve on a Pipeline, and a Merge Conflict is detected by a Promotion, your DevOps Resources with the appropriate Copado Permissions will be able to not only view, but actually correct, the Merge Conflict directly in Copado – all with points-and-clicks!
Overlap Awareness across User Stories
Even before you Promote a User Story, Copado allows you to see, directly on your User Story, any other User Stories with the same Metadata Component, where a Merge Conflict is likely so that you can proactively assign DevOps Resources to collaborate and potentially resolve the conflict prior to Promotion.
The only caveat here though is that the Pull Request will only show differences if at least one of the Overlapping User Stories has reached the master Git Branch (Production or Developer Salesforce Org).
Native Process
Create a manual tracking solution in Excel, Google Docs/Sheets, Quip or SmartSheet to track all manual Deployment Steps that must be completed, including such Deployment Steps as:
With Copado’s Deployment Steps these and other historically manual Deployment Steps can be streamlined easily – mostly with points-and-clicks!
Because Copado is built 100% native on Salesforce, you have at your fingertips all of the amazing native Salesforce features to leverage directly on the Copado application. Some examples of common native Salesforce features leveraged include:
Additionally, the Copado Development Team has been extremely thoughtful in their construction of our application, for example, having limited Visualforce Page overrides, and, in the instances where we do use Visualforce, we also include, more often than not, native Field Sets, so that you can control the User Experience.
.svg)
.svg)
.svg)