Local development involves two components:
  • Being able to create and edit getOperate scripts and flow from your favorite IDE
  • Deploy them to getOperate and at the same time version them in a Git repository
In addition to the core functionalities just mentioned, some might want to add the concept of deployment. This encompass having a staging and production getOperate environment, and being able to deploy from Staging to Production. The diagram below illustrate the full process. We’re going to explain it quickly, and in the following sections we will decompose it. It works as follows:
  • 2 different workspaces exist in getOperate: one for Staging, and one for Prod and a Git repository as we been set to sync the getOperate Staging workspace.
  • Some developers work form their favorite IDE. They can create new getOperate scripts and flows, edit existing ones, and push them to the Staging repository. Some developers can work directly in getOperate’s web IDE. All of this happen in the Staging workspace
  • Every time a script or a flow is deployed in the Staging workspace, getOperate will automatically commit the change to the Git repository. It can either commit directly to a specific (i.e. staging) branch, or open PRs to this branch (one PR per script/flow)
  • Within the Git repository, every time the staging branch is merged to the production branch (i.e. main), all the changes are pushed at once the the getOperate Production workspace.
To summarize, developers operates only in getOperate Staging workspace. getOperate Production workspace is updated only by the CI when the Git staging branch is merged to the production branch. Now let’s deep dive into the first part. We will first explain how developers can setup their local environment to be able to create and edit getOperate script from their IDE, then we will see how to sync getOperate workspaces to a Git repository.

​
Develop locally

Setting up the workspace folder Developing getOperate scripts and flows from your favorite IDE is made easy by using getOperate CLI. Here we will go through the full process of cloning a getOperate workspace locally, creating and editing new scripts and flows, and pushing them back the getOperate workspace.
Not familiar with getOperate CLI? Get started with it here
The first step is to clone an existing getOperate workspace into a local folder. Create an empty folder: 
mkdir myworkspace
cd myworkspace
Add the workspace and pull its the content using the CLI pull command: 
getOperate workspace add myworkspace [workspace_id] [remote]
getOperate sync pull --raw
INFOWe recommend using --raw here, which will soon be the default for the CLI sync command. Stateful sync is not needed here.
This will download the content of the workspace into your local folder. You will see an f/ and a u/ folder appearing, replicating the folder structure of the workspace.
getOperate sync pull will pull everything from the getOperate workspace, including resources and variables, even secrets. If you’re planning to use Git as explained below, we recommend only pulling scripts, flows and apps, skipping the rest. It can be done with:
getOperate sync pull --raw 
--skip-variables --skip-secrets --skip-resources
Each script will be represented by a content file (.py, .ts, .go depending on the language) plus a metadata file (ending with .script.yaml). This file contains various metadata about the script, like a summary and description, but also the content of the lock file and the schema of the script (i.e. the signature of its main method). We will come back to this later. For flows, one flow will be represented by a folder, containing a flow.yaml file being the definition of the flow, and additional files for inline scripts.