Collaboration with personal sandbox accounts

Introduction

This is a step-by-step guide on how to use Salto in a team setting, assuming your team has enough sandbox accounts to account for:

  • Each admin or developer has a personal sandbox
  • Shared sandboxes, at least two we will refer to as Integration and Staging

:information-source: This guide assumes you're familiar with the content on Getting started with Salto.

How to read this guide

  • The term development refers to changing your business apps' configuration, whether done by an admin or developer
  • This guide assumes you're using a project management tool (such as Jira). If you're not, feel free to skip those parts
  • This guide uses the term Jira to refer to any project management tool

Overview

This workflow walks through:

  • Developing a feature or task in a dedicated sandbox, on a Git feature branch
  • Deploying to Integration and testing your work alongside other new features
  • Deploying to Staging to test and approve a new production-ready version, on a Git release branch
  • Deploying to production, and handleany live issues using the Hotfixing flow

The workflow

Preparing for development

Action

Notes

Where

1

Create a feature branch

  • If you're new to the concept of feature branches, learn more on Recommended Git practices.
  • Make sure to branch off of main
  • Make sure to give your branch a meaningful name, usually the title of the feature or bug you're working on

Salto - operations panel

2

Change your task's status to In Progress

Jira

3

Prepare your sandbox for development

The end state of this step is to:

  • Have a sandbox dedicated to the work on your feature/task
  • Have that sandbox set up in Salto
  • Have that sandbox aligned with your shared envs where it matters

To make that happen:

  • Make sure your sandbox is configured under an Env. For more info see Configuring your first environment
  • In your workspace, make sure the current env selector is set to your env
  • Run Fetch Align, by clicking the arrow near the Fetch button
  • Run Deploy on the same env -- this makes sure your env is configured with your team's Common Config

Want to read more about Common Config? Check out How Multi-env works.

Salto - operations panel
Business app admin UI - Dev env

Development

Action

Notes

Where

1

Develop the feature/task

Do the work the same way you're used to: in your admin UI, or in tools you're familiar with (e.g. VSCode).

It's possible to develop changes in Salto, by editing NaCls. To learn more contact us.

Business app admin UI - Dev env

2

Fetch

Salto - operations panel

3

Move elements to Common Config

The goal of this step is to use Multi-env to make sure your changes are set up to be deployed to any subsequent env, such as Integration, Staging, and eventually Production.

For more information on how this works check out Fetching a change from Dev and How Multi-env works.

Salto - NaCl editor

4

Test on Dev

This is a great point in the workflow to make sure your changes work as expected. Catching issues this early is ideal - while you have full context.

Business app UI - Dev env

5

Push to Git

For how to perform this action, see Fetching a small change.

For best practices, see Recommended Git practices.

Salto - operations panel

:repeat: You can execute all these development actions in multiple iterations.

  • Doing so can make each step easier, since you have less context to keep in mind
  • For instance, when pushing to Git, more iterations result in smaller push scopes, which can be conducive to better commits - see Recommended Git practices for more

Preparing for review

Action

Notes

Where

1

Verify your Multi-env configuration is ready for subsequent envs

Verifying your config is ready to be deployed and tested on Integration and beyond is best done by previewing Salto's deployment plan to Integration, and making sure it matches your expectations.

  • Change the current env in your workspace to be Integration
  • Click Deploy; it won't deploy anything yet; it will present you with the deployment plan
  • Review the deployment plan; to be precise you can compare it to the Git diff you have on your feature branch so far (see GitHub docs on how to compare)
  • Cancel the Deploy operation

Salto

2

Create a pull request

To learn more about pull requests, see GitHub's docs.

GitHub

Review and merge

Action

Notes

Where

1

Ask your peer or manager to review your work

Reviewer

The reviewer can use different tools to assess the task owner's work:

  • Test the expected behavior of the feature, usually testing the most likely or important flows
  • Review changes via the business app admin UI
  • Review NaCl changes via Git

While feedback can be communicated in multiple ways, Salto's best practice is adding comments in the pull request.

Task owner

Upon receiving feedback, improvements should be implemented in the Dev env's admin UI, and pushed to the feature branch.

Pushing changes to the feature branch updates the pull request content, making it easy to ask the reviewer to take another look.

Iterate

Continue this flow of feedback and improvements until both parties are satisfied with the result.

GitHub and/or Business app UI - Dev env

2

Merge your pull request into main

GitHub

3

Deploy to Integration

Salto - operations panel

4

Test on Integration

Testing in this phase should be rigorous, ideally including:

  • The test plan for the new feature / bug fix
  • Additional tests that have the potential to detect integration bugs, i.e. issues that arise when your feature meets new work by others for the first time
  • Regression tests

Business app UI - Integration env

5

Change your task's status to Development Done

Jira

Delivery

Action

Notes

Where

1

Create a release branch

Release branches are based on main.

Salto

2

Deploy to Staging

Salto

3

Test on Staging

Any fixes done in this step are done on the release branch.

If the release contains commits of features you would like to exclude, perhaps because they're not stable, you can revert those commits on the release branch (do not revert them on main).

Business app UI - Staging env

4

Deploy to Production

Salto

5

Change your task's status to Delivered

Jira

6

Sync fixes back to main and Integration

  • To sync changes from the release branch back to main you can use either a pull request, or cherry-picking. For more information about cherry-picking, click here
  • If you've added any fixes on this release branch that are missing from main, make sure to deploy main to Integration once they are synced
  • If you chose to revert any commits while preparing this release, make sure to undo those reverts before syncing back with main

GitHub
Salto

Hotfixing

Action

Notes

Where

1

Deploy the latest release branch to Staging

  • Make sure your current env is set to Staging
  • Find the latest release branch on Salto or GitHub
  • Change your workspace's current Git branch via the operations panel

Salto
GitHub

2

Develop the hotfix

Business app admin UI - Staging env

3

Test on Staging

Business app UI - Staging env

4

Fetch

Salto

5

Deploy preview on Production

Similar steps as action #1 under Preparing for review

Salto

6

Push to Git

Make sure you're pushing to the latest release branch.

Salto

7

Deploy to Production

Salto

8

Sync fixes back to main and Integration

Similar steps as action #6 under Delivery

GitHub
Salto


Did this page help you?