CI/CD with Skuid

CI/CD is an acronym that refers to the several development philosophies that, when combined, aim to automate large parts of application testing, code quality, and deployment. And while CI/CD principles are typically applied to products written exclusively in code, it’s also possible to build a full CI/CD pipeline atop your Skuid development processes.

  • CI typically stands for continuous integration—where developers integrate application changes into a single, shared repository as often as possible. Each time a developer pushes code to this central repository, that code is then verified by an automated build, allowing teams to detect problems early.

  • CD can stand for two separate concepts, but they are often used in conjunction:

    • Continuous delivery mandates work within the shared repository always be deliverable, which means automating many of the processes to test and package the software.

      • Automated testing occurs whenever code changes are pushed to a team’s shared repository. This testing ensures that the application does not break when changes are made to its backend code.
      • Additionally, the packaging steps required to prepare or compile the software for release are typically included under the umbrella of continuous delivery.
    • Continuous deployment is an additional, automated software shipping strategy wherein the tested and packaged application is deployed as often as needed. The frequency of these deployments varies based on the needs of the organization.

Each of these philosophies can be implemented into an organization’s larger application lifecycle management (ALM) process. These philosophies have gained traction in many modern software development circles because they emphasize code quality and ease of deployment—two of the biggest concerns in building sustainable, effective application development. CI/CD is especially important when developing apps as a team. CI/CD ensures that everyone’s changes are incorporated into the same place, while automated testing verifies quality. Teams work faster and better together.

Where does this come in for Skuid? Skuid’s apps are composed of various metadata objects which contain the configurations that Skuid processes to display those applications. By understanding the anatomy of your applications, you can store these metadata objects in source control and create CI/CD processes around them.

Note

  • This document is intended as a general overview of CI/CD concepts and how they overlap with Skuid development. Experienced developer operations engineers may already be aware of what is listed below.
  • For the sake of discussing these concepts in the context of Skuid, the term developer will be used interchangeably with Skuid builder.

Prerequisites

Get cross-team buy-in

Implementing CI/CD can be a complicated process that requires the effort and buy-in of multiple teams. It is difficult, and often inadvisable, to do without cross-team cooperation. Because of the variety of tools and skills needed, consider assembling a cross-functional team to implement CI/CD for your Skuid implementations.

Make informed application lifecycle management choices

Application lifecycle management (ALM) can take many forms. CI/CD is often a more programmatic approach, and it may not fit the needs of your organization or your Skuid deployment.

Learn the Salesforce CLI and skuid-sfdx

The Salesforce CLI, also known as SFDX, is the primary means of programmatically retrieving, packaging, and deploying Salesforce metadata. It can be used to create scratch orgs and move metadata from one org to another per your application lifecycle management processes.

In addition, the skuid-sfdx Salesforce CLI plugin is the primary means of retrieving and deploying Skuid metadata on Salesforce. You’ll need to use this plugin in conjunction with other SFDX features to more fully take advantage of CI/CD tooling.

Continuous Integration

Choose a shared repository system and hosting platform

One of the tenets of CI/CD includes choosing a single shared repository for an application’s code—in Skuid’s case this means page XML and other metadata objects like data sources. You may choose from a variety of source control tools, such as git, SVN, or Mercurial, but this choice will impact the CI/CD tooling you may use later on.

After choosing a source control tool, you’ll need to pick a hosting service compatible with that tool. Common choices include Github and Bitbucket. The service you choose will impact which tools you may use for other stages in the CI/CD pipeline, and you’ll need to familiarize yourself with the hooks that the service uses to communicate with outside systems.

Choose a CI/CD tool

There are several factors at play when choosing a CI/CD tool for your organization. For example, some tools are proprietary, enterprise-grade tools that are designed to be more “plug-and-play” in your existing tech stack. There are also open-source, self-hosted solutions that require more extensive setup, however, they allow for more flexibility in your automation workflow. Some tools are self-hosted and others are offered as a software-as-a-service solution. There’s also a mixture of all of the above attributes among the tools available.

Some common CI/CD tools include:

Regardless of your choice, you’ll likely be scripting your CI/CD process—often called a pipeline—in a format your tool understands. These pipeline scripts often include the following:

  • A software image—for example a Docker container—for the server to use when running its commands. This ensures the server has all the software needed to build your application, test it, package it, etc.
  • Conditional when statements, i.e. the events that kick off the pipeline’s commands. These are often set from events on your shared repository system. For example, a test pipeline may only test part of a project for test branches, while a production release pipeline may run a full automated testing suite when work is merged into a release branch.

You’ll also need credentials for your staging and production platforms stored in your CI/CD tool of choice, as you’ll be retrieving data from one to send to the other.

These configurations have little to do with Skuid itself. Instead, they just determine how the metadata that makes up Skuid sites will be stored, tested, and published. Thus, Skuid builders will need to work closely with their IT organization to determine a proper ALM approach.

Continuous Delivery

Automated Testing

To ensure that an update has not broken any functionality within an application, consider implementing an automated testing pipeline stage within your CI/CD stack. By making extensive use of the unique ID property within a page’s Skuid components, it is possible to script basic test cases that can then be run within the testing framework of your choice.

For more information, see our Automated Testing topic.

Packaging

Salesforce applications—and thus applications built using Skuid—do require packaging steps before deploying to a target Salesforce org. For more information, see the Create a Package topic from Salesforce DX documentation.

Continuous Deployment

Deployment ensures that—after completing the rest of the pipeline steps—your applications are published in a form your users can access. For Skuid applications that means deploying your metadata objects or application package. Where and how that deployment is accomplished depends on your platform of choice.

Deploying Skuid metadata objects involves the skuid CLI command. If all necessary credentials are stored in the CI/CD tool, and the Skuid resources are stored within a git repository checked out by the CI/CD tool, then this pipeline stage may look like the following:

1
2
3
# Deploy that data to the production site with another set of credentials
echo "New commit merged to master. Deploying to $PRODUCTION_HOST..."
skuid push --username $PRODUCTION_UN --password $PRODUCTION_PW --host $PRODUCTION_HOST --dir skuid-data

Note

When working in Salesforce environment, you must manually recreate more of your metadata objects. For more information, see Sandboxes and Connected Orgs.

In addition to the Skuid-centric metadata used for apps, there are other pieces of Salesforce metadata that must be deployed.