Deployment tracking
How to represent your existing deployments in Sleuth
Last updated
How to represent your existing deployments in Sleuth
Last updated
Sleuth is designed to allow you to get up and running quickly with all of your existing dev, observability and CI/CD tools. Our light-weight integrations allow you to model your existing deployments in Sleuth without having to change your flow or install any invasive libraries.
Within your Sleuth Organization you can create any number of Projects. Examples of how you might use projects are:
To represent a product line your organization offers
To represent a collection of services that many of your products rely on
To represent a collection of micro-services that, together, offer a specific set of functionality
To represent business units of your organization
Sleuth creates a project for you out-of-the-box. Just name your project in the setup wizard and you're on your way.
Sleuth allows you to model your existing deployment Environments. Environments are defined and shared under a Project. Examples of how you might use an Environment are:
To represent your staging and production deploys
To represent each percentage of a Canary rollout (10%, 25%, etc)
To represent QA deployments or production deployments across different regions
Sleuth creates a Staging and Production environment for every Project by default. You may delete these if they don't correctly represent your deployments.
The heart of most software change in an organization is driven via code. A Code deployment in Sleuth (not to be confused with a Deploy in Sleuth) represents a direct mapping to a Git repository in your source control system (e.g. GitHub, Bitbucket, GitLab). You may define any number of Code deployments under a Project so Sleuth can track your code deploys. Examples of code deployments include:
The code used to deploy your main monolith application
The code used to store and deploy your Terraform infrastructure
The mono-repo code used to deploy many micro-services (you can create a deployment per service in your mono-repo)
Many teams use Feature flags to activate new code paths or features for their customers. This is just another source of change and Sleuth will treat them as such. You can connect your LaunchDarkly feature flags to a project.
Manual changes let you enter anything that you want tracked in Sleuth that isn't covered by code, feature flags, or another type of change that Sleuth currently supports. They are a free-form entry that can have any name or description you'd like. Examples include:
A manual resource scaling event
The restart of a service
An increase in your infrastructure capacity
Deploys are how Sleuth represents the changes that are made from your code deployments, feature flag and manual changes. Deploys are specific to a project, environment and change source (i.e. a Code deployment, a Feature flag, or a Manual Change) but are visible and searchable at the project and team levels. Deploys can progress through your different environments and Sleuth will show you which environments a deploy has passed through. Deploys collect all the relevant data that went into making your change and, when deploy verification is enabled via Impact tracking, shows the impact your change has made on the health of your service.
