Builds

OttoFMS and OttoDeploy work together to let you create a snapshot or version of your files which can be used as a source for deployment, or just as way to archive a particular state of your project. OttoFMS provides an API endpoint for creating a build. OttoDeploy has a user interface for configuring the builds and sending it to the API on the server.

The end result is a Zip Archive named after your build ID and a manifest.json file that contains information about the build.

Here are a few example of how you might choose to name your build and its archive name:

build-2023-03-01.zip
v10.1.33.zip

Why would I do this?

Upgrading multiple copies of a solution.

The most common reason is that you have more than one copy of your FileMaker application running on one or more servers. In this case, you probably want to create a build of a particular version of your application, and then deploy it to all of the servers. This ensures that all of the servers are running the same version of the application.

We see two common variations of this:

• Vertical market solutions that you deploy for multiple customers, on one or more servers.
• A single solution that is deployed to multiple servers in different geographical locations.

Public Builds

If you want to share a solution with the community or your customers, you can create a build and share it on the internet. How widely you share it or if it is password protected is up to you. Anyone running OttoFMS will be able to easily install it on their server if they have access to the webserver you have hosted your build on. If you follow a few guidelines you can also make it possible for people to upgrade to newer versions of your solution when you release them.

Read more about Public Builds.

What happens during a build?

When OttoFMS receives a request to create a build, it will run the following steps:

• Run the pre-build script (if configured). This is an opportunity to do anything you want before the build begins.
• Each file listed in the files property of the payload will either be cloned or copied into a new folder in the OttoFMS outbox directory.
• A manifest.json file is created with information about the build, that is used by OttoFMS to install the build, or use it as the schema source of a deployment.
• The new build folder is zipped up and the archive is named with the build ID.

Configure Builds with OttoDeploy

OttoDeploy has a user interface for configuring builds. You can access this by clicking on the Builds tab in the sidebar.

The builds in OttoDeploy are the recipes that you use to create builds. They can be re-used, duplicated, and adjusted. After running a build, they are stored on the OttoFMS server and can be used as a source for a deployment.

Just in Time Builds

Deployments can be configured to create a build just before the deployment begins. This is in fact what happens when you use the Simple settings to run a deployment. Under the hood we call this a "just in time" build.

This type of deployment is the most similar to how things worked in Otto v3 and earlier.

You can see this in OttoFMS Developer API documentation for starting a deployment. The deployments[0]source property of the payload can be one of several options including otto4jit. That option tells OttoFMS to create a build on the source server before starting the rest of deployment. Once the build is done, OttoFMS fetches the newly creating build and uses it as the source for the deployment.

The "just in time build" is deleted from the source server once the deployment is complete.

Build Archive Options

OttoFMS and OttoDeploy have settings that let you adjust the compression level and the memory usage of the build process. You can adjust these settings in the OttoDeploy Build detail screen, and the Deployment detail screen if you are using a just in time build.

Increasing compression level will make the archive smaller, but it will take longer to create the archive. Increasing the memory limit will allow the build to use more memory, which can make the build process faster.