<commit_before>- [Puppet change process. With integration branch](#puppet-change-process-with-integration-branch)
- [Change process](#change-process)
    - [1 - USER: Open a ticket [trivial skip] [express skip]](#1---user-open-a-ticket-trivial-skip-express-skip)
    - [2 - PUPPET TEAM: Prioritize and assign tickets [trivial skip] [express skip]](#2---puppet-team-prioritize-and-assign-tickets-trivial-skip-express-skip)
    - [3 - PUPPET DEVELOPER: Development](#3---puppet-developer-development)
    - [4 - PUPPET DEVELOPER: Testing [trivial skip] [express skip]](#4---puppet-developer-testing-trivial-skip-express-skip)
        - [Simplified Alternative using integration branch](#simplified-alternative-using-integration-branch)
        - [Simplified Alternative using web interface](#simplified-alternative-using-web-interface)
    - [5 - PUPPET DEVELOPER: Merge Request [trivial skip] [express skip]](#5---puppet-developer-merge-request-trivial-skip-express-skip)
    - [6 - PUPPET DEVELOPER: Production rollout](#6---puppet-developer-production-rollout)
- [Simplified Change process using web interface](#simplified-change-process-using-web-interface)

### Puppet change process. With integration branch

In this document we will review a possible process to follow to manage `Puppet` changes based on an `integration branch`, used as `origin` and controlled promotion to `production branch`.

It's based on `Gitlab CI pipelines` defined in the [gitlab/.gitlab-ci.yml-integration](gitlab/.gitlab-ci.yml-integration) file.

It can be used as main ```.gitlab-ci.yml``` file on a setup where code stays in a (local) `GitLab` instance and the `Puppet server` is based on `Puppet Enterprise`, with automatic code deployment whenever a change is pushed to `GitLab server`.

This can be adapted to custom tools and needs, with variations in internal organisation and processes.

By `Puppet changes` we mean, any modification, addition or deletion in this `control-repo` which may involve changes on real server, once the change has been deployed to the `Puppet Server`.

### Change process

Each non trivial change on this `Git repository` should follow a workflow as the one outlined here. We will mark with the label **[trivial skip]** the steps than can be skipped for trivial changes.

An express path might be considered for very urgent changes, such as fixes for current outages or for very urgent user requests. We will mark with the label **[express skip]** the steps which might be skipped in such cases.

#### 1 - USER: Open a ticket [trivial skip] [express skip]

Normally every change should be tracked by a relevant ticket on the `Ticketing System` of choice. This should be done by the user requesting the change (only as exception operators should open tickets by themselves for requests arrived by email, voice or other means). Ticket title should be informative and not generic and in the description should be added details such as:

  - What has to be changed (content of a file, user password, package installation ...) and how
  - Where the change should occur (a specific server, all servers or a `role/datacenter/environment...`)
  - If the change should be applied at specific times or conditions (changing a file may involve a ```service restart```, is this supposed to be done only in maintenance windows?)
  - If the request is for fixing a malfunctioning system, any detail on the kind of failure and eventually suggested solutions


#### 2 - PUPPET TEAM: Prioritize and assign tickets [trivial skip] [express skip]

Ideally is not the user who decides who has to fix his problem, but the team of `Puppet admins`. Prioritization and assignment should be handled directly on the `Ticketing System`. Decisions on them can be done by the `team leader`, by the whole team in regular meetings (e.g. stand-ups) or autonomously by each member (a `Puppet operator` self assigns an open ticket and starts to work on it).

Using `Kanban boards` to map tickets to cards can help the process.

#### 3 - PUPPET DEVELOPER: Development

The assigned team member starts to work on the ticket, he should have a ready to use workstation where he can develop and test his `Puppet code`. Any change should be pushed to ```integration branch``` **only**. The `CI` process [semi]automatically takes care to promote the change to ```production branch```.

A good approach is to create a ```feature branch```, with the relevant `name` and relevant `ticket number`. Once the changes on the ```feature branch``` have been merged into ```integration```, and then up to ```production```, and the relevant `ticket` closed, the ```feature branch``` should be removed.

Remember to always create a ```feature branch``` based on current status of ```integration branch```. First we have to checkout into ```integration branch```:

    git checkout integration

Then it's always recommended to `sync` the `local branch` to `origin` so that we are sure we are working on updated code:

    git pull origin integration

Then we can create a ```new branch``` with the name referring to the relevant ticket:

    git checkout -b feature_22

Finally we can start to edit our files and make our developments:

    vi ....


#### 4 - PUPPET DEVELOPER: Testing [trivial skip] [express skip]

We have at disposal several ways to test our `Puppet code`:

  - We can test our changes on our local development workstation, using the available [vagrant](vagrant.md) environments (this can be done before any commit)<commit_msg>Minor: correct link reference, wording<commit_after>- [Puppet change process. With integration branch](#puppet-change-process-with-integration-branch)
- [Change process](#change-process)
    - [1 - USER: Open a ticket [trivial skip] [express skip]](#1---user-open-a-ticket-trivial-skip-express-skip)
    - [2 - PUPPET TEAM: Prioritize and assign tickets [trivial skip] [express skip]](#2---puppet-team-prioritize-and-assign-tickets-trivial-skip-express-skip)
    - [3 - PUPPET DEVELOPER: Development](#3---puppet-developer-development)
    - [4 - PUPPET DEVELOPER: Testing [trivial skip] [express skip]](#4---puppet-developer-testing-trivial-skip-express-skip)
        - [Simplified Alternative using integration branch](#simplified-alternative-using-integration-branch)
        - [Simplified Alternative using web interface](#simplified-alternative-using-web-interface)
    - [5 - PUPPET DEVELOPER: Merge Request [trivial skip] [express skip]](#5---puppet-developer-merge-request-trivial-skip-express-skip)
    - [6 - PUPPET DEVELOPER: Production rollout](#6---puppet-developer-production-rollout)
- [Simplified Change process using web interface](#simplified-change-process-using-web-interface)

### Puppet change process. With integration branch

In this document we will review a possible process to follow to manage `Puppet` changes based on an `integration branch`, used as `origin` and controlled promotion to `production branch`.

It's based on `Gitlab CI pipelines` defined in the [gitlab/.gitlab-ci.yml-integration](../gitlab/.gitlab-ci.yml-integration) file.

It can be used as main ```.gitlab-ci.yml``` file on a setup where code stays in a (local) `GitLab` instance and the `Puppet server` is based on `Puppet Enterprise`, with automatic code deployment whenever a change is pushed to `GitLab server`.

This can be adapted to custom tools and needs, with variations in internal organisation and processes.

By `Puppet changes` we mean, any modification, addition or deletion in this `control-repo` which may involve changes on real server, once the change has been deployed to the `Puppet Server`.

### Change process

Each non trivial change on this `Git repository` should follow a workflow as the one outlined here. We will mark with the label **[trivial skip]** the steps than can be skipped for trivial changes.

An express path might be considered for very urgent changes, such as fixes for current outages or for very urgent user requests. We will mark with the label **[express skip]** the steps which might be skipped in such cases.

#### 1 - USER: Open a ticket [trivial skip] [express skip]

Normally every change should be tracked by a relevant ticket on the `Ticketing System` of choice. This should be done by the user requesting the change (only as exception operators should open tickets by themselves for requests arrived by email, voice or other means). Ticket title should be informative and not generic and in the description should be added details such as:

  - What has to be changed (content of a file, user password, package installation ...) and how
  - Where the change should occur (a specific server, all servers or a `role/datacenter/environment...`)
  - If the change should be applied at specific times or conditions (changing a file may involve a ```service restart```, is this supposed to be done only in maintenance windows?)
  - If the request is for fixing a malfunctioning system, any detail on the kind of failure and eventually suggested solutions


#### 2 - PUPPET TEAM: Prioritize and assign tickets [trivial skip] [express skip]

Ideally is not the user who decides who has to fix his problem, but the team of `Puppet admins`. Prioritization and assignment should be handled directly on the `Ticketing System`. Decisions on them can be done by the `team leader`, by the whole team in regular meetings (e.g. stand-ups) or autonomously by each member (a `Puppet operator` self assigns an open ticket and starts to work on it).

Using `Kanban boards` to map tickets to cards can help the process.

#### 3 - PUPPET DEVELOPER: Development

The assigned team member starts to work on the ticket, he should have a ready to use workstation where he can develop and test his `Puppet code`. Any change should be pushed to ```integration branch``` **only**. The `CI` process [semi]automatically takes care to promote the change to ```production branch```.

A good approach is to create a ```feature branch```, with the relevant `name` and relevant `ticket number`. Once the changes on the ```feature branch``` have been merged into ```integration```, and then up to ```production``` branches, and the relevant `ticket` closed, the ```feature branch``` should be removed.

Remember to always create a ```feature branch``` based on current status of ```integration branch```. First we have to checkout into ```integration branch```:

    git checkout integration

Then it's always recommended to `sync` the `local branch` to `origin` so that we are sure we are working on updated code:

    git pull origin integration

Then we can create a ```new branch``` with the name referring to the relevant ticket:

    git checkout -b feature_22

Finally we can start to edit our files and make our developments:

    vi ....


#### 4 - PUPPET DEVELOPER: Testing [trivial skip] [express skip]

We have at disposal several ways to test our `Puppet code`:

  - We can test our changes on our local development workstation, using the available [vagrant](vagrant.md) environments (this can be done before any commit)
{'fraction_non_alphanumeric': 0.08673238672334267, 'fraction_numerical': 0.0032558560188116125, 'mean_word_length': 4.402051783097216, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2744272', 'n_tokens_mistral': 2988, 'n_tokens_neox': 2780, 'n_words': 1482}