How Takeoff works with DTAP environments

Schiphol Takeoff deploys your application to any environment on your cloud. Your CI provider pulls the Schiphol Takeoff image from dockerhub. Takeoff determines the state of your git repository (i.e. what branch your commit is on) and will decide where the deployment should go.

ci-envs

For example, this is how one can use Schiphol Takeoff:

  • feature branches will be deployed to your development environment;
  • master branches will be deployed to acceptance;
  • git tags are considered releases and are deployed to production.

It will also make sure versions are preserved during deployment to these environments — given the previous example

  • development will receive a version equal to the name of your feature branch;
  • acceptance will receive the version SNAPSHOT;
  • production will take the git tag as version.

Concretely this means that many feature branches may be running simultaneously, but only one SNAPSHOT or git tag will be running.

For this all to work, Schiphol Takeoff makes some assumptions about naming conventions. For example, in the case of Microsoft Azure, each of these environments basically mean a separate resource group. These resource groups are identical in the fact that they contain the same services, but otherwise might be different in terms of scaling and naming of services. Based on naming conventions Schiphol Takeoff determines during CI which service in which resource group it should deploy to.

note: The above holds for the defaults of Schiphol Takeoff, all of the above logic can be overridden by plugins.

ApplicationVersion

One of the most important classes in Schiphol Takeoff is ApplicationVersion. It has the following signature:

@dataclass(frozen=True)
class ApplicationVersion(object):
    environment: str
    version: str
    branch: str
  • environment is the environment Schiphol Takeoff should deploy to. This value is used to resolve any naming rules set in .takeoff/config.yml. Examples of this value could be dev, PRD, acceptance;
  • version is the version of the application and also the version each artifact or service should get;
  • branch is the current git branch.

Here is an example of how Takeoff determines to which environment a deployment should go:

from takeoff.application_version import ApplicationVersion
from takeoff.credentials.branch_name import BranchName
from takeoff.util import get_tag, get_short_hash

def deploy_env_logic(config: dict) -> ApplicationVersion:
    branch = BranchName().get(config)
    tag = get_tag()
    git_hash = get_short_hash()

    if tag:
        return ApplicationVersion("PRD", str(tag), branch)
    elif branch == "master":
        return ApplicationVersion("ACP", "SNAPSHOT", branch)
    else:
        return ApplicationVersion("DEV", git_hash, branch)

Without knowing too much about specifics of the code one can see that git tags go to production, master branches go to acceptance and other features branches go to development.