Getting started

Set up your environments

An environment is an Aprimo instance you work in day to day: its address, plus the credentials Mochi uses to reach it.

An environment is one of your Aprimo instances, like a sandbox to try things out, a QA instance to check them, and production. Each one carries two things: the instance's address, and the credentials that let Mochi read your configuration (and update it when a change is delivered). Set one up for each instance you use.

Add an environment

In your workspace, choose Add environment. Mochi signs in and checks its access before anything is saved, so you know straight away that it works.

Name it. A short label like “Dev” is what you'll see everywhere in Mochi.
Enter the subdomain. The first part of your Aprimo address: enter acme for acme.aprimo.com. This identifies the instance and can't be changed later.
Enter the Client ID and Client secret. Mochi doesn't show the secret again once it's saved, so keep your own copy.

Where the Client ID and secret come from

Create a client-credentials registration in Aprimo and use its Client ID and secret here. Its user needs to be able to read and write configuration. If it can only read, Mochi can compare and review, but delivering a change will fail.

Add an environment for each Aprimo instance you work with. A sandbox, a QA instance, and production can all live side by side, so you can move a change from one to the next.

Mark your production environments

An environment can be marked as production. These are the live instances everything else works toward. From an environment's menu, choose Mark as production, and it carries a Production badge from then on. You can mark more than one.

Production follows one shared configuration

All of your production environments share the same configuration. A change captured in one of them becomes part of that configuration, and the other environments catch up through their normal delivery path. You can also bring a fix made in production back down to your sandboxes when you need to.

Which environments belong on a pipeline

Put every environment a configuration change passes through on the pipeline, in the order it should reach them. That includes the sandbox where changes get made, not just the ones further along.

It's tempting to leave the sandbox off on the grounds that changes are already in there. The reason to include it is what it does for the environments after it. A stage can only be brought as far as the stage in front of it has already reached, so a sandbox at the front of the pipeline is what stops a change reaching production before the sandbox has it.

Leave the sandbox off and production sits at the front of the path instead, with nothing ahead of it. There's also the everyday case of a fix made in production: with the sandbox on the pipeline, it comes back down the path like anything else.

Mochi goes on what an environment actually holds

Mochi keeps track of the configuration each environment has really received, rather than assuming a sandbox is up to date because that's where people work. An environment can fall behind, and having it on the pipeline is what lets it catch up.

Reviewing an environment

Open an environment and choose Review. Mochi reads the configuration that's in it right now and shows you how it compares with what you track, sorted into Changed and Not tracked. That's what you'll pick from when you build your first change set.

Your first change set

Open an environment, pick what changed, and turn it into something reviewable.

PreviousWelcome to Mochi Deploy NextYour first change set