Applications

Applications are software components that run together. Noop Applications map one-to-one with a code repository. An Application can be a single service (possibly with a database requirement) or a monorepo that includes a collection of services, tasks, and resources.

Define an Application using the Noop blueprint.yaml configuration in the project’s .noop directory. The blueprint.yaml is responsible for defining all aspects of your Application, including:

• Components: static assets, scheduled tasks, and container services
  • Build processes for each Component
  • Runtime details for each Component
• Resources: MySQL, Postgres, Redis, Amazon S3, and Amazon DynamoDB
• Routes: definitions of which routes serve each static and service Component

The Application dashboard in the Noop Console contains links to Builds, repositories (Source Code), Environments, and Pipelines (CI/CD).

Builds

Each Component must define its own build process. Components can contain defined Build Variables/Secrets available during run steps within the build process. The container in the final build step will be used for the Component’s runtime.

Source Code

Applications can be linked to a repository to integrate with its code and events automatically. Linked repositories connect Source Code to Builds and trigger Pipelines.

Environments

Environments are instances of the Application. They contain their own Resources, Runtime Variables/Secrets, and scaling configuration. Typically, environments are created once and remain active indefinitely (e.g., a prod or staging environment). However, it’s also possible to create temporary preview environments in response to a pull request.

Pipelines

Pipelines are a series of instructions (a workflow) initiated by a repository event. Once initiated, the pipeline can manage any aspect of an Application. Typically, this process involves deploying a new Build to a specific Environment in response to a source code push on a specific branch.