Skip to main content

The Development Lifecycle

A change reaches production by moving through five stages. Some happen in Koodisi, and some happen in your Git provider — GitHub, GitLab, or Azure DevOps. Knowing which stage lives where is the key to working confidently.

The sequence: Develop → Dev → QA → push → review → merge → publish from the target branch → approve and promote → monitor.

StageWhere it happens
1. DevelopKoodisi
2. Deploy and validateKoodisi
3. Push, review, mergeKoodisi (push) → Git provider (review, merge)
4. Deploy to productionKoodisi
5. MonitorKoodisi

Koodisi has two environments: Development and Production. There is no intermediate environment — validation happens in Development, and promotion moves a deployment from Development to Production.

Stage 1: Develop​

Build in Koodisi on a feature branch, with your application connected to a Git repository for version storage.

  1. Open your Git-enabled application. If you don't have one yet, see Creating a Git-Enabled Application.
  2. Open the Version Control panel and check out the branch you want to start from — usually your main or master branch — so your new branch inherits the right starting point.
  3. Create a feature branch from the Branches tab. If your organization has branch naming patterns enabled, select a Branch Type and the prefix is applied for you. See Git Branching Policy.
  4. Build your workflows, schemas, and resources. Commit often with clear messages.

Your work lives in your browser's LocalDataStore until you push it. Push regularly — LocalDataStore is browser-specific, so an unpushed change exists in exactly one place.

Stage 2: Deploy and validate​

Publish a version and deploy it to Development so QA can confirm the change behaves as expected.

  1. Publish the workflow to lock an immutable version. See Publishing Workflows.
  2. Deploy that version to the Development environment.
  3. Validate the behavior. To test against a specific deployment profile's configuration, send the X-Profile-Name header with your request. See Managing Application Deployment Profiles.

Fix and re-publish as needed. Only move on once Development behaves the way you expect.

Stage 3: Push, review, merge​

Push from Koodisi, then review and merge in your Git provider.

  1. In the Changes tab, stage your changes, then use Commit and Push to send them to your feature branch on the remote.
  2. Go to your Git provider and raise a pull request from your feature branch to the target branch.
  3. Have your team review it there. Review every changed file, not only the ones you expected to touch — a schema or resource edit shows up as its own file.
  4. Merge the pull request in the Git provider, using the merge strategy your organization has agreed.
info

Merging one branch into another always happens in your Git provider. Koodisi has no merge or squash action, and cannot move individual commits between branches. Raising and merging a pull request in GitHub, GitLab, or Azure DevOps is the required path — it is what gives you team review and keeps protected branches protected.

Pull does merge: it integrates remote commits into the branch you have checked out. What it cannot do is complete a merge that conflicts.

Choosing a merge strategy​

Your provider decides how the pull request lands, and Koodisi works the same way whichever you pick. Squash and merge is the usual choice for feature branches: you commit as often as you like while building — which Koodisi encourages, since unpushed work lives only in your browser — and the target branch keeps one clean commit per completed feature.

Two things follow from squashing. The individual commit messages are discarded, so the squashed commit message is where the reason for the change has to live. And the squashed commit is a new commit, so delete the feature branch after merging and create a fresh one from the updated target branch rather than continuing on it.

Do not squash or rewrite history on shared branches such as develop, main, or a release branch. For the full comparison, see Merging and Pull Requests.

After the merge, select More > Fetch & Prune in Koodisi so your list of remote branches reflects the branches that still exist. See Using Git with Applications.

Stage 4: Deploy to production​

warning

Check which branch you are deploying from. Publishing captures the application as it exists on your currently checked-out branch. If you publish while still on your feature branch, you publish that branch's state — not the merged result your team reviewed.

  1. In the Version Control panel, check out the target branch you merged into.
  2. Pull so your local copy includes the merged changes from every contributor.
  3. Confirm the Version Control panel shows the target branch as checked out.
  4. Publish a version from this branch, and deploy it.
  5. Select Promote on the deployment. This sends an approval request to the designated approvers.
  6. Once approvers approve, the deployment moves to Production.

If a promoted version causes problems, use Rollback on the Deploy page to restore a previously deployed version. See Publishing Workflows.

Stage 5: Monitor​

Watch how the change behaves once it is live. The Metrics Dashboard shows executions, failures, and runtime behavior for your deployments. See Monitoring Deployments and Channels.