Salto allows you to manage your business applications' configuration in code. By doing so, it enables modern devops style methodologies for development, testing and deployment for these business applications.
Salto consists of 3 main components:
- The NaCl language — a declarative configuration language (follows the syntax of hcl), specifically designed to describe the configuration of modern business applications.
- The Salto command line interface — a tool which uses NaCl files to manage the configuration of business applications, with operations such as
deploy
(to deploy configuration changes to a business application) andfetch
(to fetch the latest state of a business application into NaCl files). This tool is composed of a core processing engine, and various adapters to interact with the different business applications. - The Salto vs-code extension — An extension to the popular vs-code IDE to easily interact with NaCl files.
For more information, see the user guide and the FAQ.
To report issues or ask about using the Salto CLI - please join our public Slack channel here.
Please head to our releases page. There you'll find prebuilt binaries for major OSes (MacOS, Linux, Windows).
See the vscode package documentation
docker build --tag salto-cli
docker run salto-cli
- Install Node.js 14 (for M1 Macs use 14.15). You can download it directly from here, or use Node Version Manager (NVM) (simply run
nvm use
) to install it. - Install yarn 1.
- Fetch dependencies and build:
$ yarn
$ yarn build
$ yarn test
By default, yarn test
will run only unit tests - stored at the tests
directory of each package.
E2E (end-to-end) tests are stored at the e2e_tests
directories. To run them, define the RUN_E2E_TESTS=1
environment variable:
RUN_E2E_TESTS=1 yarn test
E2E tests are run on CircleCI builds, and you should also run them locally before creating a PR.
Important E2E tests for the cli
and salesforce-adapter
need valid SFDC credentials to run.
Salto is versioned using the semantic versioning scheme. Therefore, when composing a new release, we would:
- Bump the version in the packages'
package.json
files. For that, we're usinglerna
- Tag the git repository with the new version
- Publish the packages in this repo to npm
- Build artifacts and attach them to a new release in this repository
Here is how to do it:
Install GitHub CLI and configure it (for example by running gh pr status
).
Make sure you're on main
, no local changes, CI status is passing, and run:
yarn lerna-version-pr [BUMP]
Where BUMP is a lerna version; default is patch
This will create a PR labeled VERSION
. Once the PR is merged, the version will be published and a git tag will be created.
yarn lerna-version [BUMP]
Submit a PR and have it merged.
Once the PR is merged, the version will be published and a git tag will be created.
See READMEs of individual packages under the packages
directory.