As a DevOps engineer we all understand the pain of managing source code and repositories. Now add to that scale and complexity of CI/CD and the source code system administrator has a full time job just maintaining and configuring repo’s.

After embarking on a automation journey using Bitbucket and Bitbucket pipelines as a wholistic CI/CD tool the management of the repo’s became quite complex when creating pipelines, deployments and deployment variables.

1. Bitbucket pipelines is the integrated CI/CD service built into Atlassian Bitbucket, more on that here.
2. Bitbucket Deployments are a mechanism to deploy your code to different environments and allow you to setup specific environment variables for each, more on that here.

The solution:

Since the above states how to create, manage and maintain the repository, pipeline, deployments and deployment variables manually there seemed to be a need to be able to handle that in a automated way.

At Digitalis.io we strive to make things simpler by removing any obstacles and allowing DevOps Engineers to focus on what matters most : INNOVATION.

The https://github.com/digitalis-io/tf-bitbucket-repo-mgmt repository will allow any bitbucket admin to create and manage repos in a automated way. Simplifying the need to repeat the same steps and process on multiple repositories. A centralised DevOps CI/CD way of managing your Bitbucket repositories if you like.

The input is 2 list of variables.

1. A list of repositories with the deployments(environments) that you want to add.
2. A list of the deployments and the deployment variables.

If there are no deployments in the repository variable it will just create a repository without any deployment environments or deployment variables.

The tool is flexible enough and allows you to manage both CI/CD and non-CI/CD repositories.

Example of the variables :

1. repo_deployment_list (list of repo’s that can have n-amount of deployments)

{
    "repo_deployment_list": [
        {
            "repo_name": "The name of the repository", //Required
            "repo_owner": "The Owner of this repository", //Required
            "project_key": "If you want to have this repo associated with a Project e.g. DEVOPS", //Optional
            "deployments": [
                "deployment_or_env_name_1",
                "deployment_or_env_name_2"
            ], //Optional if enabling pipelines and deployments
            "description": "This will be the repository description", //Optional
            "fork_policy": "1 of 3 options : no_forks, allow_forks or no_public_forks", //Defaults to allow_forks
            "is_private": true, //Defaults is true, option to make fork publicly available on bitbucket.
            "pipelines_enabled": true //Optional if enabling pipelines and deployments
        },
        {
            "repo_name": "REPO_NUMBER_2", //Required
            "repo_owner": "The Owner of REPO_NUMBER_2", //Required
            "project_key": "If you want to have this repo associated with a Project e.g. DEVOPS", //Optional
            "deployments": [
                "deployment_or_env_name_1",
                "deployment_or_env_name_2"
            ], //Optional if enabling pipelines and deployments
            "description": "This will be the repository description", //Optional
            "fork_policy": "1 of 3 options : no_forks, allow_forks or no_public_forks", //Defaults to allow_forks
            "is_private": true, //Defaults is true, option to make fork publicly available on bitbucket.
            "pipelines_enabled": true //Optional if enabling pipelines and deployments
        }
    ]
}

2. deployment_variable_list, can be any variables that are used for a specific deployment. It can be n-amount of key-value pair variables you would need for a deployment environment.

Please note that the below list of deployment names need to match the above list of deployment names. e.g deployment_or_env_name_1

The below example is used to deploy to multiple AWS accounts.

{
    "deployment_variables_list": {
        "deployment_or_env_name_1": {
            "stage": "Test", //Required. options are Test,Staging or Production
            "environment": "dev",
            "region": "eu-west-2", //Can be any of the AWS regions
            "aws_account": "a user friendly AWS account name e.g. Dev or Staging or Prod",
            "aws_acces_key": "your_aws_secret_key",
            "aws_secret_key": "your_aws_secret_access_key"
        },
        "deployment_or_env_name_2": {
            "stage": "Test", //Required. options are Test,Staging or Production
            "environment": "stage or staging",
            "aws_account": "a user friendly AWS account name e.g. Dev or Staging or Prod",
            "region": "eu-west-2", //Can be any of the AWS regions
            "aws_acces_key": "your_aws_secret_key",
            "aws_secret_key": "your_aws_secret_access_key",
            "Tag_Environment": "Test",
            "Tag_Team": "Could be a internal team name"
        }
    }
}

NB. Please note that the variable names and structure is very important for the tool to work. The variables are JSON format to allow easy integration with Hashicorp Vault and most third party secret stores.

Final steps:

Once you have all the repositories created you can start setting up and monitoring your bitbucket-pipeline.yml, deployments and CI/CD solution. This process is really well documented here.

‍