Create Sprints and User Stories in Snapshot

Snapshot can now create Sprints and User Stories that help Salesforce administrators manage complex Orgs with collaborative projects and teamwork automation. Project managers can create Sprints and assign User Stories to individual developers and administrators. These individual contributors can add metadata assets and deployment tasks to their User Stories. Lastly, a release manager can deploy the User Stories into any destination Salesforce Org, developer project, or online repository. Let’s take a quick look at what you can do with Sprints and User Stories!

Manage Sprints

The Manage Sprints interface is where project managers can create, edit, and delete Sprints and assign User Stories to individual contributors. Sprints can be managed with a simple to do list, a Kanban Chart, or a Gantt Chart. A simple Sprint might be managed with a to do list. A more complex Sprint might be managed with a Kanban Board. A long running Sprint might need to be managed like a project with Gantt Charts. You can use all of these visualizations at the same time or focus on one in particular. Here is the first tab of the Manage Sprints interface.

Teamwork Automation

You can turn on awesome teamwork automation features for any Sprint and send email notifications when a Sprint is created, deleted, deployed, or assigned a new owner. You can also notify individual contributors when a User Story is created, deleted, assigned, or when the Kanban Stage changes. Sprints make collaborative Org Management a breeze!

Kanban Boards

You can view your Sprints with a Kanban Board in both Snapshot and Salesforce Lightning. The Kanban Stages are shown across the top of the board with team members displayed down the left-hand side. Kanban Boards help manage work by showing which team members are available and the current stage of all the Stories. User Stories can be reassigned to different Stages or team members by dragging and dropping the cards on the board.

Gantt Charts

Every Sprint also has an optional Gantt Chart interface. Each User Story is displayed as a task bar on the chart. Gantt Charts are useful for long running projects where some Stories must be completed before other Stories can begin. The Gantt Chart will calculate the amount of time for the entire project if some stories are delayed or contingencies change.

Burndown Graphs

Keep track of Sprint progress with a Burndown Graph. This graph shows when a Sprint is behind or ahead of schedule.

Update Story

The Update Story interface is for individual contributors that have been assigned User Stories by a project manager. The Story Owner can add metadata assets and manual deployment tasks to their User Story. This information is saved with the Story for collaborative use by other team members. The metadata assets attached to the User Story can be tested in context and saved.

Pull Request

When the User Story is finished, the Story Owner can make a pull request that moves the Story into deployment. The Sprint Owner is notified via email about the pull request.

Global Templates

Some deployment tasks will be part of any Sprint. For this reason, we have added the ability to create global task templates that can be reused. Each task contains the option to launch the source or destination Salesforce browser and to run a command line. The browser can be used to start a manual operation with the setup menu. The command line results will be included in the Sprint History when the task is completed.

Overlap Awareness

All of the Sprint and User Story interfaces provide instant Overlap Awareness if other team members are using the same metadata assets that you are. Item on the Job List will appear in red if they are overlapped with other User Stories in the same Sprint. The tooltip for the field will show who else is using the object and the name of their User Story.

The final tab looks similar to the regular deployment interface. The Update Story button will save all of the selected deployment tasks and metadata assets into the current User Story. The Test Deployment button will conduct a validating deployment using the selected assets against the destination Org.

Deploy User Stories

The Deploy User Stories interface is designed for release managers who need to deploy a Sprint or User Story into an Org, a developer project, or an online repository. This interface could also be used by an individual contributor who wants to move a User Story into a Scratch Org or some other destination.

Merge Conflicts

If the two developers are working on the same piece of metadata, then there is a conflict and the merge panel will be displayed. In the picture below we can see that one object has a description and the other does not. Since adding a description is nondestructive, the left hand Accept button is automatically highlighted indicating the best way to resolve the conflict. Every aspect of the merge process is guided by the user interface. This is way better than trying to resolve conflicts in a text editor!

At any point the release manager can select the Automatic Merge option and look at the conflict map. This shows all of the component parts of the metadata asset across the top of the screen and all of the conflicting User Stories down the left-hand side of the screen. The conflict map can be exported for review by the engineering team.

In some cases, a release manager might be tempted to send the conflicting User Stories back to the individual contributors and let them figure it out. The Notify Owners button will send an email to the Story Owners, along with an attachment that contains the conflicting asset data and the conflict map.

Metadata Comparison

Some Sprints will not have any asset overlaps, and in other cases the Merge Conflicts interface must be used to resolve problems. When all of the selected User Stories have been merged into a single metadata source, then the release manager can compare the assets against the destination Org.

The next tab begins the deployment process for the merged User Stories. First, the before deployment tasks are completed and checked off one by one. In some cases, a deployment task might launch a browser to begin setup menu changes or to run a command line test. When all of the before deployment tasks are completed the release manager can proceed to the next tab and deploy the assets.

The Deploy Assets tab is very similar to the regular deployment interface. You can deploy User Stories into a destination Org, developer Project, or online repository. When you are finished, complete the deployment by completing the after tasks checklist on the last tab.

Sprint History

Every time you complete a User Story deployment the full history of what happened is added to the Sprint History object. This records the list of deployed User Stories, the before and after tasks that were successfully completed, and the results of the deployment.

Conclusion

There you have it! This Blog has covered some of the cool new features behind Sprints and User Stories. You will need the latest Managed Package for Snapshot version 3.5 to start using the new User Story capability. Let us know if you need help. If you want more information, please check out the User Story whitepaper below:

https://www.metazoa.com/best-practices-sprints-and-user-stories/


The New Code Quality Report

Snapshot has an amazing new Code Quality Report that can identify many common programming flaws in any Apex Class. You can schedule the Code Quality Report to run after any Snapshot and send a PDF, CSV, or HTML file to admins or developers with all of the various problems that were found. Super admins can even set up a Code Quality Gateway to prevent selected programming problems from being deployed to any org! Let’s dig in and take a look at this new capability.

Installing PMD

The Code Quality Report uses the PMD open source static code analyzer. Nobody is really sure what PMD stands for, but this is the gold standard for analyzing Apex code and finding common programming flaws. The open source PMD project is the foundation for most of the code quality systems available on the Salesforce platform. You will need to be sure that PMD is installed on your local machine. Snapshot uses PMD through the command line interface. PMD is a Java application, so you will also need to be sure that Java is installed, if it is not already. You can learn more about PMD here:

https://pmd.github.io/

We have simplified the PMD installation process as much as possible. The first tab of the Apex Code Quality dialog has a button at upper right called “PMD Connection.” Click that button, and there will be various links and information about how to install PMD. When you are ready, click the “Test Installation” button, and Snapshot will tell you if PMD is installed or not. You can also return to this screen and update the version of PMD that you are using. The path to the current version is in the pathname above the button.

Apex Code Quality

Once PMD is installed, you can right-click any Snapshot item and select “Apex Code Quality” from the popup menu. You can also use the Options Menu at the top of the screen. The dialog below will appear, and you can see all of your Apex Classes at left. Click on any class name and the middle section will show you various problems with the code. You will see the Rule Set and Rule that was violated. Scrolling to the right, the report details the seriousness of the problem, the impacted line numbers, and a detailed explanation of how to fix the issue. Click on any rule and the lines of code that are causing the problem will be highlighted at right.

This first tab provides an easy way to quickly preview all of your Apex Classes and review any code problems. You can click down the list of issues and see all of the affected lines of code at right. Right-click the center table to export all of the problems as a CSV, HTML, or PDF file. If you check multiple Apex Classes at left, then all of the selected items will be included in the final report under the middle tab.

Understanding Quality Results

PMD divides code quality problems into seven categories:

  • Best Practices
  • Code Style
  • Design
  • Documentation
  • Error Prone
  • Performance
  • Security

Each category contains different rules. There are about 45 different rules that PMD uses to analyze Apex code. A full description of each rule is documented in the Snapshot interface. Each rule is assigned a number between 1 (highest priority) and 5 (lowest priority). The priority numbers for each rule can be assigned in the Snapshot interface. In this manner, you can decide what rules are the most critical or least important. Rules can also be removed from consideration completely if desired.

  • Priority 1) Change Absolutely Required
  • Priority 2) Change Highly Recommended
  • Priority 3) Change Recommended
  • Priority 4) Change Optional
  • Priority 5) Change Highly Optional

Managing Code Quality

Right-click the center report on the first tab or click the “Manage Quality” button on the second tab to assign each of the available rules a priority. In the example below, we have assigned rules regarding Code Style and Best Practices to be optional, while rules regarding Security and Performance are absolutely required. If there are some rules that you would like to ignore entirely then uncheck the “Include Rule in Report” checkbox.

Automating Code Quality

Just like other reports in Snapshot, you can schedule and automate the Code Quality Report. In the last tab, select the event to trigger the report, and then send a PDF, CSV, or HTML file to an email list or Chatter group. Alternatively, the report could be saved to Salesforce Content or a local folder. Code Quality Reports can be conditional, and only sent out if changes are required in the code. In this manner, any org can be monitored for code quality, and a full report is generated and delivered if there are problems.

Conclusion

There you have it. Snapshot now has a state-of-the-art code quality analysis and monitoring system. Be sure to give this new feature a try and let us know how it works for you.


Introducing Data Migration For Snapshot

Metazoa has added some powerful new tools to Snapshot that move connected sets of data between Salesforce orgs. This capability is useful for backing up data, refreshing Sandboxes, merging orgs, and populating orgs with test data. Now Snapshot can move metadata to a destination org and follow up by migrating the actual data as well. Both of these transactions can be scheduled as needed.

When records are migrated between orgs, all of the internal relationships are preserved. External references in the Dataset are also connected to matching objects on the destination. You can also select the fields used for matching destination objects. For example, you might want to match Accounts by Name and BillingCity.

There are capabilities to map objects and fields to new names, and to scramble fields to obscure personal or financial information. You can also import Datasets from other systems with CSV files. Our new CSV file format provides a simple way to import, merge, and connect data to any destination org.

Snapshot uses the Salesforce Bulk API for this new feature to ensure that very large Datasets can be moved efficiently. We have tested Snapshot by moving hundreds of thousands of records. This blog presents an overview on how to build and migrate Datasets. Find more detailed technical documentation here:

https://www.metazoa.com/publications/dataset_migration_v3.pdf

Getting Started

Simply restart Snapshot and you will automatically get the new Data Migration capability. When you right-click a Deployment Arrow, the second set of options will have new commands to Build, Import, and Migrate Datasets. If you do not see these commands, then perhaps the Deployment Arrow is connected to a Developer Project. They do not have any actual data and cannot be used as a source of data or as a destination for migration.

The option to Build a Dataset will use the source Salesforce org to download multiple records in the form of XML files to your local machine. The option to Import a Dataset will use CSV files from any source to create a new Dataset as well. Lastly, the option to Migrate a Dataset will insert and update records from the selected Dataset into the destination Salesforce org.

Building Datasets

The first tab of the Build Dataset dialog allows you to select parent objects that you want to include in the Dataset. These records are available on the source Salesforce org. You can select all records, a subset of records by name, or a subset of records using a complex filter. The total number of downloaded records can be limited. This is useful for grabbing a random subset of records for acceptance testing or application development.

Selecting Children

The next tab allows the selection of connected child objects for each parent object. When a Dataset is created, the selected parent records are loaded first, followed by all of the children connected to that parent. You can specify multiple child objects in a hierarchy. The relationship field used to associate each parent and child is shown in parenthesis. The internal relationships between parent and child are always preserved when the Dataset is migrated.

Loading Fields

After that, you can select fields to load for each parent and child object. You can choose fields that need to be loaded by moving them to the list at right. Fields that cannot be created or updated on the destination do not usually need to be loaded. Removing unwanted fields makes your Dataset smaller in size and easier to migrate.

Build Datasets Button

The next tab allows you to enter the name of a new Dataset and then click the Build Datasets button at right to start the download process. All of the download results will be listed in the window pane at lower right. The Dataset will be saved in XML files to your local machine. Snapshot is an extremely secure solution, because we never move your data or metadata to any third-party cloud or Salesforce org! The last tab allows you to schedule the creating of a Dataset at a specific time in the future or as a recurring event.

Importing Datasets

There is another way to create a Dataset. The Import Dataset command is right under Build Datasets when you right-click a Deployment Arrow. When you Import a Dataset, you can select any number of CSV or XML files and add them to the list at left. The interface will show the imported fields and source records in the window panes at right.

Snapshot has introduced a new CSV file format that simplifies the process of merging and connecting CSV data with any destination Salesforce org. Check out our technical documentation for all of the details on how to prepare CSV files in this format:

https://www.metazoa.com/publications/dataset_migration_v3.pdf

Mapping Fields

The Mapping Fields tab provides an easy way to make sure that the imported object and field names match up to the object and field names in the destination org. First, select the desired destination object name at top. Then go down the list and select matching field names. The same technique applies to matching external references and fields.

Finish Importing

The last tab allows you to enter the name of a new Dataset and then click the Import Datasets button at right to start the import process. If you select an existing Dataset name from the menu then that Dataset will be replaced. When you want to migrate that data to an actual Salesforce org you will need to use the Migrate Dataset dialog, explained in the next section.

Migrating Datasets

After a Dataset has been created, you are ready to migrate these records to a destination Salesforce org. Right-click a Deployment Arrow that is connected to the correct destination org and select the Migrate Datasets option to get started. The Migrate Datasets dialog allows you to select any of the global Datasets from the list at left and see the objects and fields that are available in the list at right.

Matching Fields

Snapshot lets you select the fields used to match records on the destination org. One powerful way to match destination objects is with External Ids. Other common matching fields include object names, email addresses, and usernames. Some Salesforce sandboxes have the same Ids as production orgs. In that case you can simply use the Id field for matching destination objects.

Scrambled Fields

Datasets are often used to move records into a Salesforce Sandbox or Developer Edition for testing or application development. In these situations, you may want to scramble data records that contain sensitive information. These fields might contain financial information, such as credit cards or bank accounts, or personal information, such as email addresses or Social Security numbers. The Scramble Fields tab provides an easy way to select fields that you want to obscure in the destination org.

Deactivate Assets

When a Salesforce record is inserted or updated, various Apex Triggers, Workflow Rules, and Validation Rules might be invoked. These automated behaviors can cause potentially undesirable effects during data migration. For example, thousands of emails might be sent out, or some records might not be updated. The Deactivate Assets tab provides an easy way to deactivate Apex Triggers, Workflow Rules, and Validation Rules in the destination org before data migration is attempted. After migration, the deactivated triggers and rules will be turned back on.

Migrate Datasets Button

The next tab has the main interface for migrating datasets to the destination org. First, make sure that the migration options are set correctly. Then click the Migrate Datasets button to get started. If any errors are encountered, they will be written to the Log Files along with the Salesforce record Ids.

There You Have It!

We are stoked that Snapshot can handle Datasets as well as Metadata. This is a great new product addition. Please give this capability a test drive and let us know how Datasets are working for you.

Register for our Webinar on December 12th at 10:00 a.m. PST to see it in action.


Salesforce User Group Roundup

I've started traveling the country talking to Salesforce Developers and User Groups. Salesforce is in an interesting transition from great product to full-fledged Enterprise Platform. This is a great opportunity for ISV's and Salesforce Administrators alike to build some insanely great new applications that leverage these new capabilities. Everybody is curious about the role of Salesforce DX, and how we used Salesforce DX to supercharge Snapshot 2.0 Change and Release Management.

My talk starts with a discussion about the platform transition at Salesforce, and the role of Salesforce DX. Next, I show some command line examples about how to create a Scratch Org and Push and Pull source from a Developer Project. Many of the new SFDX capabilities were used to create Snapshot as well. Developer Projects can be downloaded from any repository, the files can be harvested, and then turned into a snapshot. Scratch Orgs and Dev Hubs can be connected to your Snapshot Workflow. Support for Second-Generation Packages is on the way, and Developer Controlled Packages can be pushed between Orgs.

Boston Salesforce Developers Group

Salesforce DX: Quick Start, App Development Model, and Continuous Integration

Our intrepid host, Bing Wang, taught a hands-on developer workshop all about using the Salesforce DX Command Line. He covered the lion's share of Salesforce DX capabilities in just about an hour. After that, I spoke about how we used Salesforce DX to connect Source-Driven Development to the Change and Release Process. Thanks for the invitation Boston! We'll see you guys again at DreamForce this year.

Kansas City Salesforce User Group

Next up I visited the Kansas City Salesforce User Group. The audience consisted of Salesforce Administrators, Salesforce Developers, and Power Users. The Kansas City area has a thriving Salesforce community, and this was great to see in person. Our host Dale Zeigler led a lively and wide-ranging discussion about many aspects of Salesforce development. My talk was well received, and there were quite a few questions about how we used Salesforce DX for application development and Change and Release Management.

-----

PRESENTATION

Salesforce is at an inflection point moving from application to platform. This is a great opportunity for ISV developers who want to build new products and enterprise architects who want to tackle new initiatives. Salesforce DX is a key part of this strategy, providing a source-driven programming environment and better organization of developer projects with second-generation packages.

Bill Appleton wrote the first AppExchange application DreamTeam in 2005, and one of the most popular administrative tools Snapshot in 2006. Now working on Snapshot 2.0, Bill will show how he used Salesforce DX to harvest developer repositories and allow administrators to create scratch orgs on the fly. Working together, Snapshot and Salesforce DX connect developer projects to the change and release management process.

BIOGRAPHY

Bill Appleton is a leading expert on the use of web services for smart client applications. He has designed and written approximately three dozen professional software publications, including the first rich media authoring tool World Builder in 1984, the ground breaking multimedia programming language SuperCard in 1989, the worldwide best selling CD-ROM Titanic in 1996, the first AppExchange application DreamTeam in 2005, and the first API Automation Platform DreamFactory in 2010, and Snapshot 2.0 Change and Release Management for Salesforce in 2018.

Bill previously served as the President of the gaming company CyberFlix where he worked closely with Disney, Paramount, Viacom, and Bandai. After that, he was the President of DreamFactory Software, which developed an open source REST API platform for HTML5 and native mobile applications. Currently, he is the CTO at Metazoa building the world's best change and release management application for the Salesforce ecosystem. Many leading computer publications and mainstream magazines have featured Bill’s work, including People Magazine, Newsweek, and US News and World Report.

Specialties: web services, authoring tools, smart clients