​
Versioning

Scripts, when deployed, can have a parent script identified by its hash. Indeed, scripts are never overwritten, they are instead subsumed by a child script which corresponds to the new version of the parent script. This guarantees traceability of every action done on the platform, including editing scripts. It also enables versioning. Versioning is a good practice from software engineering which everyone familiar with git already knows. getOperate versioning is a simplified git with two simplifying assumptions:
  • Linearity: the lineage or the chain of Scripts from the one with no ancestor/parent to the one with no child is linear - there is no branching and there is no merging.
  • Not diff-based: every version of a Script contains its entire content and not just the diff between it and its direct parent. This is for simplicity and read-performance sake.

​
Script Hashes

Versions of Scripts are uniquely defined by their hashes. They are an immutable reference similar to a git commit SHA. Scripts also have a path, and many versions share the same path. When a script is deployed at a path, it creates a new hash that becomes the “HEAD” of the path. The previous “HEAD” is archived but still deployed forever. When a script is saved, it is immediately deployed.

​
Git Sync

From the workspace settings, you can set a git_repository resource on which the workspace will automatically commit and push scripts, flows and apps to the repository on each deploy. All scripts, flows and apps located in the workspace will be pushed to the Git repository, except the ones that are saved in private user folders (i.e. where the path starts with u/, use those with f/ instead). Filtering out certain sensitive folders from the sync will be available soon. On each deployment, only the updated script/flow/app will be pushed to the remote Git repository. For the Git repo to be representative of the entire workspace, it is recommended to set it up using the getOperate CLI before turning this option on. Run the following commands from the git repo folder to push the initial workspace content to the remote: 
> echo 'includes: ["f/**"]' > getOperate.yaml
> getOperate sync pull --raw --skip-variables --skip-secrets --skip-resources
> git add -A
> git commit -m 'Initial commit'

​
CLI Sync

Synchronizing folders & git repositories to a getOperate instance is made easy using the getOperate CLI. Syncing operations are behind the getOperate sync subcommand.

​
Raw Syncing

Raw syncing will soon become the default. Raw syncing is a one-off operation with no state maintained. When using getOperate EE and Git Sync, this is what you should use since Git Sync will always keep your git repo up-to-date. When not used in with Git Sync. It’s best used for making backups, cloning a complete workspace, and similar one-off operations. Raw syncing is done using getOperate sync pull --raw & getOperate sync push --raw

​
Pulling

getOperate sync pull --raw will simply pull all files from the currently selected workspace and store them in the current folder. Overwrites will not prompt the user. Make sure you are in the correct folder or you may loose data.

​
Pushing

getOperate sync push --raw will simply push all local files to the currently selected workspace, creating or updating the remote equivalents.

​
Stateful Syncing

Stateful syncing is currently the default but will soon require the —stateful flag Stateful syncing is best used when your Git repo and getOperate workspace might diverge (because of not using Git Sync) and you want to keep track of the state the last time you pulled to check for merge conflicts.The CLI will automatically maintain state for you and ensure modifications that happen concurrently on the remote and locally stay in sync.

​
Pulling

Pulling with getOperate sync pull will first update the internal sync state, and then generate a diff between your local files and this state, only updating the actually modified files. Possible conflicts will warn the user.

​
Pushing

Pushing with getOperate sync push will push all local files to the remote and then update the internal state to avoid being out-of-sync due to the push. Using sync push without --skip-pull will start the push by doing a pull first to ensure the user is not overriding changes made to the remote.

​
Pull API

The getOperate sync pull command is used to pull remote changes and apply them locally. It synchronizes the local workspace with the remote workspace by downloading any remote changes and updating the corresponding local files. 
getOperate sync pull [options]
OptionparameterDescription
--fail-conflictsNoneError on conflicts (both remote and local have changes on the same item).
--yesNonePull without needing confirmation. The command proceeds automatically without user intervention.
--rawNonePull without using state, just overwrite. The command operates in raw mode without utilizing local state tracking.
--plain-secretsNonePull secrets as plain text. Secrets are downloaded without encryption or obfuscation.
--jsonNoneUse JSON instead of YAML. The downloaded files are in JSON format instead of YAML.

​
Push API

The getOperate sync push command is used to push local changes and apply them remotely. It synchronizes the remote workspace with the local workspace by uploading any local changes and updating the corresponding remote files. 
getOperate sync push [options]
OptionparameterDescription
--fail-conflictsNoneError on conflicts (both remote and local have changes on the same item).
--skip-pullNonePush without pulling first. Assumes that the pull operation has already been performed.
--yesNonePush without needing confirmation. The command proceeds automatically without user intervention.
--rawNonePush without using state, just overwrite. The command operates in raw mode without utilizing local state tracking.
--plain-secretsNonePush secrets as plain text. Secrets are uploaded without encryption or obfuscation.
--jsonNoneUse JSON instead of YAML. The uploaded files are in JSON format instead of YAML.

​
How raw mode works

  1. Pulls remote changes and applies them locally. 
    getOperate sync pull
  2. Pulls remote changes without using state tracking. Overwrites local files with remote changes. 
    getOperate sync pull --raw
  3. Pushes local changes and applies them remotely. 
    getOperate sync push
  4. Pushes local changes without using state tracking. Overwrites remote files with local changes. 
    getOperate sync push --raw