Salto OSS monorepo

   

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:

1. The NaCl language — a declarative configuration language (follows the syntax of hcl), specifically designed to describe the configuration of modern business applications.
2. 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) and fetch (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.
3. 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.

You can contact us by email at [email protected], or join our public Slack channel here.

Installing salto

CLI

Please head to our releases page. There you'll find prebuilt binaries for major OSes (MacOS, Linux, Windows).

VSCode extension

See the vscode package documentation

Building from source

1. Install Node.js 12. You can download it directly from here, or use Node Version Manager (NVM) to install it.
2. Install yarn.
3. Fetch dependencies and build:

$ yarn
$ yarn build

Running tests

$ yarn test

E2E tests

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.

Creating a release

Salto is versioned using the semantic versioning scheme. Therefore, when composing a new release, we would:

1. Bump the version in the packages' package.json files. For that, we're using lerna
2. Tag the git repository with the new version
3. Publish the packages in this repo to npm
4. Build artifacts and attach them to a new release in this repository

Here is how to do it:

TL;DR Quick method

Install hub and configure it (for example by running hub ci-status). Make sure you're on master, 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.

Create a PR manually

1. Create a new version

yarn lerna-version [BUMP]

2. Commit and push the version to git

Submit a PR and have it merged.

Once the PR is merged, the version will be published and a git tag will be created.

Usage instructions

See READMEs of individual packages under the packages directory.

License

Apache License 2.0