# Prepare app repository

Set up branch rulesets, and manual deployment approval for your application repository.

## Step 1: Protect your default branch

Your repository automatically inherits a set of branch rulesets from the GitHub organization when you add a specific custom property to it. These rulesets add a set of required guardrails to your repository to protect your default branch.

### Step 1.1: Set `gp-repository-type`

The value of the custom property should reflect your repository type:

- **Application repository**—the repository contains code for a single application, while the associated infrastructure lives in a separate IaC repository, such as `pirates-iac`.
- **Application repository with infrastructure**—the repository contains both application code and the associated infrastructure for a single application.

Select the tab that matches your repository type:

=== "Application repository"
Go to **Settings** > **Custom properties** and set `gp-repository-type` to `app`.

=== "Application repository with infrastructure"
Go to **Settings** > **Custom properties** and set `gp-repository-type` to `hybrid`.

After setting the custom property, verify that **Settings** > **Rulesets** shows rules inherited from the organization.

### Step 1.2: Remove overlapping rulesets

The organization-level rulesets from the previous step replace any repo-level rulesets that Utviklerflyt has already set up for you - if any. If your repository has repo-level rulesets such as "Protect default branch" or "Require team approval", these can now be removed. [Contact Utviklerflyt](../../help/contact-us.md) if you are unsure which to remove.

## Step 2: Protect GitHub Actions environment targeting production

This enables manual approval for deployments to production, and ensures that deployments to production only can be made from the default branch. This should **only** be set up for production, not for other environments.

<!-- prettier-ignore-start -->
!!! info "Manual approval"
    You can turn off manual approval of production deployments if you want to, but enabling it during initial setup of the new deployment pipeline is a **strongly recommended practice** to reduce the risk of negatively affecting your production environment.
<!-- prettier-ignore-end -->

1. Go to **Settings** > **Environments** > **New environment**
1. Set the name to match the name of your production environment:
   - For an application repository: `<environment>`, such as `pirates-prod`
   - For an application monorepo: `<environment>-<app-name>`, such as `pirates-prod-swordsmith`
1. Set **Required reviewers** to your GitHub team
1. Click **Save protection rules**
1. Under **Deployment branches and tags**, select **Selected branches** and add your default branch (`main` or `master`)

## Step 3: Disable existing workflows

If the application has existing GitHub Actions workflows that can conflict with the new deployment pipeline, disable (or delete) them before merging:

1. Go to **Actions** in the repository
1. Select the workflow to disable
   - If you're using the Boilerplate template `docker-build-push` to generate GitHub Actions workflows in your repository, disable or delete these. These workflows are suffixed with `- Build and push Docker image and send tag as dispatch event 🚀`.
1. Select **...** (three dots) and choose **Disable workflow**

[Contact Utviklerflyt](../../help/contact-us.md) if you are unsure which to disable.

## Next steps

[Add deployment pipeline](add-deployment-pipeline.md) for your application.