This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Branch Configuration

1: Main branch stages

Branch configuration

Description of the process for the configuration of branches in the Release Train Manager

Branch configuration file

The configuration of branches is defined in the branch-config.yml file.

Each stage defined in the schema is fully described in the Stages section.

Properties

Property	type	description	default	mandatory
name	string	Name of the branch. The format is: `[main\|hotfix\|fasttrack\|release]/description#jira-id` Example: `name: main/doc-review#14820`	none	true
release_branch	string	Name of the base branch from which the specific branch is generated.	master	In hotfix and fasttrack branches
release_version	string	Version of the base branch from which the branch will be generated.	none	In release branches
environment	string	English letter name to indicate the environment number to be generated to deploy the components used in the special branch.	none	If an environment is needed: from `one` to `ten`
mode	string	It specifies whether the branch that has been generated is to make a “real” change to the repositories to perform a test.	production	Use `developer` for test purposes
version	string	Version of configuration file.	1.0.0	Not used yet
description	string	Brief description of the changes for which the branch has been generated.	Fake text	true
jira	Jira	Jira references and tags referring to the task that the branch solves.	Fake data	true
teams	Map<string,Team>	List of teams involved in the resolution of the task solved by this branch.	none	At least one
main_protection	Object	Protection that will be applied to main branch when created in the RTM repository. This configuration can be partial and will be merged with the default configuration. All the documentation concerning the protection of a branch can be found at Github	Defined by Template	true
protection	Object	Default configuration property, this configuration will be merged between custom protection configurations of teams or main branches. All the documentation concerning the protection of a branch can be found at Github	Defined by Template	true

Jira Property

Property	type	description	default	mandatory
tags	string[]	String words used in Jira to categorize the feature or bug.	Fake data	true
references	string[]	Jira URLs where the tasks that the branch solves once the life cycle is completed are	Fake data	true

Team Object

It contains a set of common properties and others customized by each team. In the following table, the properties that are shared by all teams are described.

Property	type	description	default	mandatory
repositories	string[]	List of repository names involved in the changes to be made to the branch.	Defined by Template	true
protection	Object	Security configuration of the branches to be generated in the repositories. This configuration can be partial and will be merged with the default configuration. Example: protection: restrictions: users: [] teams: - aura-ci - aura-bot-global-dev - aura-bot-ext-devs apps: [] All the documentation concerning the protection of a branch can be found at Github	Defined by Template	true
stages	Map<string,string[]>	Map of stages in which the team has a series of steps to perform. All steps that must be performed to complete the phase.	Defined by Template	true
tasks	string[]	List of custom tasks to be completed before closing the PR for the branch. These tasks will be converted into a checkbox component in the body of the Pull Request	Fake data	false

Team Bot Custom Properties

Description of the bot’s custom properties.

Property	type	description	default	mandatory
update_dependencies	Object[] of {name: string, version: string}	List of objects with name and version. This property is used to update dependencies on the modules in the repositories defined by aura-bot. All the modules that use one of the libraries in the list, will be updated to the version that has been specified.	[]	false
dependencies	Object[] of {name: string, version: string}	List of objects with name and version. This property contains those @telefonica libraries that are needed in the Github library repository to isolate dependencies. At the INIT stage, the system will pick up that library from NPM and publish it to Github.	[]	false
node_version	number	Version of node to use in the bot’s Workflows.	14	true
tools	Object	It currently contains only one property, POEditor, which specifies the creation of a separated project to manage the localization strings.	Defined by Template	false

Branch config File

name: master
environment: none
mode: production
version: 1.0.0
description: Text to describe the release changes
jira:
  tags:
    - MyTag
  references:
    - "https://jira.tid.es/browse/AURA-12941"
    - "https://jira.tid.es/browse/AURA-13210"
teams:
  bot:
    update_dependencies: []
    repositories:
      - aura-aog-bridge
      - aura-services-api
      - aura-bot-common
      - aura-clients
      - aura-bot-libraries
      - aura-bot-libraries-test
      - aura-bot-platform
      - aura-bridge
      - aura-code-generator
      - aura-locale-importer
      - aura-movistar-libraries-utilities
      - aura-terms-and-conditions-api
      - aura-utilities
      - aura-kpis-uploader
      - aura-docs
    node_version: 14
    dependencies:
      - name: baikal-sdk
        version: 0.10.1
      - name: baikal-sdk
    tools:
      po_editor:
        project_base: Aura-Bot
    protection:
      restrictions:
        users: []
        teams:
          - aura-ci
          - aura-bot-global-dev
          - aura-bot-ext-devs
        apps: []
    stages:
      init:
        - install-dependencies
        - create-branch
        - store-locales
        - prepare-repository
        - create-changelog
        - protect-branch
        - install-tools
      start:
        - unprotect-branch
        - trigger-deploy-components
        - protect-branch
        - validate-deploy-components
      prepare-to-merge:
        - update-locales
        - check-conflicts
        - merge-and-update-versions
        - publish-modules
        - trigger-deploy-components
        - validate-deploy-components
      close:
        - unprotect_branch
        - prepare-versions-to-master
        - merge-to-master
        - validate-deploy-components
      finalize:
        - remove-main-branches
        - uninstall-tools
        - remove-packages
    tasks:
      - Review documentation before closing
      - Review PoEditor content before closing
      - Review performance before closing
  devops:
    repositories:
      - aurak8s
    stages:
      init:
        - create-branch
        - initial-commit
        - check-environment
        - create-environment
        - deploy-environment
        - unprotect-tests-branch
        - upload-environment-files
        - protect-tests-branch
        - protect-branch
      prepare-to-merge:
        - check-conflicts
        - merge
      close:
        - check-environment
        - close-environment
        - delete-environment
        - merge-to-master
    protection:
      restrictions:
        users: []
        teams:
          - aura-ci
          - aura-devops-admin
          - aura-global-cto
        apps: []
  qa:
    repositories:
      - aura-tests
    protection:
      required_status_checks:
        strict: false
        contexts: ['continuous-integration/jenkins/pr-head']
      enforce_admins: true
    tests:
      smoke_tests_enabled: false
      wa_mobile_tests_enabled: false
    stages:
      init:
        - create-branch
        - prepare-repository
        - protect-branch
      start:
        - sanity-tests
      prepare-to-merge:
        - unprotect-branch
        - check-conflicts
        - merge
        - protect-branch
        - smoke-tests
      close:
        - unprotect-branch
        - restore-repository
        - unprotect-master
        - merge-to-master
        - protect-master
        - smoke-tests

  nlp:
    repositories:
      - aura-cognitive-container
    repository_components: complex_logic,context-4p-synchronizer,context_provisioning,context,nlp-provisioning,nlp
    stages:
      init:
        - create-branch
      prepare-to-merge:
        - check-status-container
      close:
        - merge-to-master
    tasks: []

  training_nlp:
    repositories:
      - aura-nlpdata-es
    release_branch: release/7.0
    stages:
      init:
        - create-branch
      prepare-to-merge:
        - create-all-main-prs
        - check-status-repositories
      close:
        - merge-to-master
    tasks: [ ]

  legacy:
    repositories:
      - aura-cognitive-containers
    protection:
      restrictions:
        users: []
        teams:
          - aura-ci
          - aura-platform-tech-leads
          - aura-global-cto
        apps: []
    stages:
      init:
        - create-branch
        - prepare-repository
        - protect-branch
      prepare-to-merge:
        - check-conflicts
        - unprotect-branch
        - merge
        - protect-branch
      close:
        - unprotect-branch
        - update-version
        - unprotect-master
        - merge-to-master
        - protect-master

main_protection:
  restrictions:
    users: []
    teams:
      - aura-ci
      - aura-global-cto
    apps: []

protection:
  required_status_checks:
    strict: false
    contexts: []
  enforce_admins: false
  required_pull_request_reviews:
    dismissal_restrictions:
      users: []
      teams:
        - aura-ci
    dismiss_stale_reviews: true
    require_code_owner_reviews: true
    required_approving_review_count: 2
    bypass_pull_request_allowances:
      users: []
      teams:
        - aura-ci
  restrictions:
    users: []
    teams: []
    apps: []
  required_linear_history: false
  allow_force_pushes: false
  allow_deletions: false
  block_creations: false
  required_conversation_resolution: false

1 - Main branch stages

Main branches stages

Description of the different stages for main branches in the Release Train Manager

The following diagram shows the Release Train Manager stages for main branches:

All phases of the main branches are managed by the workflow: .github/workflows/push-to-main.yml.

name: Push To Main
on:
  push:
    branches:
      - "main/**"
      - "hotfix/**"

jobs:
  load-configuration:
  ########
  # INIT #
  ########
  prepare-init-process:
  protect_branch_main:
  init-bot-module:
  init-devops-module:
  init-legacy-module:
  init-models-module:
  init-nlp-module:
  init-training-nlp-module:
  init-qa-module:
  #########
  # START #
  #########
  start-bot-module:
  start-qa-module:
  ####################
  # PREPARE TO MERGE #
  ####################
  block-close:
  prepare-to-merge-bot-module:
  prepare-to-merge-training-nlp-module:
  prepare-to-merge-qa-module:
  prepare-to-merge-legacy-module:
  prepare-to-merge-devops-module:
  #########
  # CLOSE #
  #########
  close-bot-module:
  close-devops-module:
  close-qa-module:
  close-legacy-module:
  close-nlp-module:
  close-training-nlp-module:
  ############
  # FINALIZE #
  ############
  finalize-bot-module:

  process-result:

Main Init stage

In this phase, the branches are generated in the repositories and, if there is a configured environment, it will be deployed. As in every stage, each team defines its own steps, but some of them are shared and executed by any of the teams.

Common steps

Create branch

This step gets the list of repositories of the team (from branch-config.yml file, teams.*.repositories) which step is being executed and creates the corresponding main branch in all of them. If the branch already exists, it just goes on.

Protect Branch

Once all the initial changes are applied in each package of each main branch, they are protected to force the creation of a Pull Request to merge changes on them. It is executed after every stage of the RTM, because it needs the branch to be unprotected during its execution, to make changes automatically.

Unprotect Branch

RTM stages need to remove repositories’ branches protection to apply changes automatically in the code. It is executed at the beginning of almost any stage of the RTM.

Check conflicts

This step is executed during prepare-to-master stage to check if there is any conflict between master and the main branch in any configured repository. Any conflict will be reflected in the RTM as a message in the corresponding PR.

Init Bot Steps

Bot: Install dependencies

In this step, the dependencies defined in teams.bot.dependencies are installed. The tgz of the NPM module is obtained and installed in the Github repository. This is necessary because the main branch works in isolation and uses Github as the main repository.

Bot: Store Locales

In this step, all the locales files of every package in every repository are stored in DB. They are stored in the collection called branch-locales.

Bot: Prepare Repository

In this step, all the dependencies of every package in every repository are updated. Internal node packages (those belonging to @telefonica NPM organization) in master branch are read from npm registry and a x.y.z version is used. But each main branch uses for the internal dependencies a private GitHub npm registry and the dependencies are tagged with the decodedName of the branch: version: 7.5.0-main-my-feature.0.

Packages are read in order, so first those packages without internal dependencies are processed. They are published in GitHub registry and those packages depending on them are then processed, going on recursively.

Bot: Create Changelog

This step is responsible for creating the changelog scaffolding for the current version.

Bot: Install Tools

A new project is created in POEditor to include the language resources to be contained in this main branch. The project is created by auradev@tid.es user and its name will be the branch decoded name: main/feature-desc#id -> main-feature-desc-id. This project is intended to contain all the changes (creations or updates) of locales for the issues being resolved in this main branch.

Main Start stage

In this phase, all the components configured in branch-config.yml and that were prepared during the init stage will be deployed if an environment has been configured for the current branch. Afterwards, the sanity test plan is launched just to validate that the environment is properly settled. If no environment is configured (for instance, if a branch is just to review documentation or to prepare something specifically for a given OB, such as language trainings) tests are not executed.

Start Bot Steps

Bot: Trigger Deploy Components

A push is launched in the repositories of the components to force them to be deployed from CI job running in Jenkins. After each component is deployed, Jenkins sends a notification to GitHub to inform of the status, that is updated in the RTM API database.

Bot: Validate Deploy Components

This step is in charge of validating that all the components that are configured for the current branch have been deployed. It reads the information from the RTM API database that is updated with every notification from Jenkins, as explained in the previous step.

Main Prepare-To-Merge stage

This phase aims to merge master changes in the current main branch, deploy the updated version in the branch in configured environment, if exists, and launch the complete functional test plan to validate the full code base before merging to master.

Prepare-To-Merge Bot Steps

Bot: Update Locales

This step is in charge of updating the locales files in all repositories doing a merge into the main poEditor project and Aura-Bot PoEditor project.

Bot: Merge and Update Versions

Once the eventual conflicts have been resolved in all repositories configured in the branch, the content of master and main branches are merged together. In the happening of any change, tagged versions are automatically updated to provoke a new deployment of the components.

Bot: Publish Modules

If new versions have been generated in any of the bot npm libraries, a new version of them is published and updated in all the components.

Main Close stage

In this phase, all the components will be deployed in master and the libraries published in NPM. The versions of the modules will be updated if the repositories have been changed along the development in the main branch.

Close Bot Steps

Bot: Prepare versions to master

As already mentioned, bot versions in master are not tagged but in x.y.z format. This step calculates the next version of each library and component automatically depending on the existing version in master, the original semantic version and the number of changes in its tagged version in the main branch. If a library or a component has been updated in a main branch, no matter the number of commits needed for the change, its semantic version in master will be increased by 1 in the minor counter. For instance, if the version in master for library my-library is 6.2.0, and my-library has some changes in the current branch, its version in master after merging the main branch, will be 6.3.0.

Bot: merge to master

If new versions have been generated in the libraries, changes are merged and the libraries are published in @telefonica private npm registry.

Finalize step

In this phase, all the branches created, packages installed in Github and the POEditor project are deleted.

Finalize Bot Steps

Bot: Remove Main Branches

The main branch created in the repositories is removed.

Bot: Uninstall Tools

This step removes the POEditor project created for the language resources of this main branch.

Bot: Remove Packages

This step removes the packages created in the branch for each library.