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
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 |
| Salto - operations panel |
2 | Change your task's status to | Jira | |
3 | Prepare your sandbox for development | The end state of this step is to:
To make that happen:
Want to read more about Common Config? Check out How Multi-env works. | Salto - operations panel |
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 |
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.
| 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:
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 | GitHub | |
3 | Deploy to Integration | Salto - operations panel | |
4 | Test on Integration | Testing in this phase should be rigorous, ideally including:
| Business app UI - Integration env |
5 | Change your task's status to | Jira |
Delivery
Action | Notes | Where | |
---|---|---|---|
1 | Create a release branch | Release branches are based on | 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 | Business app UI - Staging env |
4 | Deploy to Production | Salto | |
5 | Change your task's status to | Jira | |
6 | Sync fixes back to |
| GitHub |
Hotfixing
Action | Notes | Where | |
---|---|---|---|
1 | Deploy the latest release branch to Staging |
| Salto |
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 | Similar steps as action #6 under Delivery | GitHub |
Updated 4 months ago