Commit c111e5f8 authored by Fredy PULIDO's avatar Fredy PULIDO 🇨🇦
Browse files

temporal commit for review only, do not merge

parent 31f38b65
# Jekyll pipelines
## Jekyll multi-environment on GitLab Pages
* **pre-production** automatically deployed when `master` branch changes
* proposed domain name: *pre-subdomain.example.com*
* Restricted access to gitlab project members
* **production** automatically deployed for changes in `production` branch
* proposed domain name: *subdomain.example.com*
### GitLab projects
GitLab offer one GitLab Page per project then we require one GitLab project per environment but only one is the real project:
* **Primary project (Prod env)**
* Contains Jekyll code used by the main pipeline to generate and deploy the website.
* The GitLab Page of this project is used to automatically deploy *production* (`production` branch).
* Example: https://ci.linagora.com/linagora/communication/corporate-website/next-website-project/corporate-website
* **Secondary project (Pre-Prod env)**
* Almost empty (no code or project management) but configured to run the secondary pipeline
* The GitLab Page of this projet is used to deploy *pre-production*
* `master` automatically deployed
* Any other branch excepting `production` requires a human to click in a button to get deployed
* Example: https://ci.linagora.com/linagora/communication/corporate-website/next-website-project/corporate-website-production
Neither of this repositories supposed to have a `.gitlab-ci.yml` file. If your project already have one please remove it to avoid misunderstandings.
### Primary project configuration
* Create (from `master`) a new branch named `production`
* Settings / General / Merge requests / Merge method:
* `Fast-forward merge` (clean git log, avoid braking repo)
* Settings / Repository / Protected Branches:
* `master` (default)
* Allowed to merge: `Developers + Maintainers`
* Allowed to push: `Developers + Maintainers`
* `production`
* Allowed to merge: `Maintainers`
* Allowed to push: `No one`
* Settings / CI-CD / General pipelines / Custom CI configuration path:
* `ci-jekyll-gl_pages-primary.yml@publicgroup/templates/gitlab-ci-yml`
* Settings / CI-CD / Variables :
* CI_SECONDARY_PROJECT_ID:
* Value: Get from the **secondary project** [General Settings](https://docs.gitlab.com/ee/user/project/settings/index.html#general-settings)
### Secondary project configuration
* Ensure that `master` is the only branch in this project
* Ensure that `master` only contains a `README.md` file with this content:
* `WARNING: Read [README-jekyll.md](https://ci.linagora.com/publicgroup/templates/gitlab-ci-yml/blob/master/README-jekyll.md) before to do anything.`
* Settings / CI-CD / General pipelines / Custom CI configuration path:
* `ci-jekyll-gl_pages-secondary.yml@publicgroup/templates/gitlab-ci-yml`
* Settings / General / Merge requests / Merge method:
* `Fast-forward merge` (clean git log, avoid braking repo)
* Settings / Repository / Protected Branches:
* `master`
* Allowed to merge: `No one`
* Allowed to push: `No one`
### GitLab Pages configuration
* Primary project:
* Settings / General / Visibility, project features, permissions / Pages
* Enabled **Everyone**
* Secondary project:
* Settings / General / Visibility, project features, permissions / Pages
* Enabled **Only Project Members**
* Read [GitLab pages custom domains configuration](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/index.html#set-up-pages-with-a-custom-domain)
* Ask IT to create the required domains for each environment.
### Running pipelines
If you did your setup correctly for Primary and Secondary GitLab projects then:
* The pipeline of Primary will start at any commit, and will deploy the result of master in Production and the result of any other branch in Pre-production.
* The pipeline of Secondary will be triggered from Primary to deploy Pre-production
### Workflow
Jekyll projects usually have two types of contributors:
* **Content developer**: write articles and upload images for the website, usually from GitLab Web interface.
* **Theme developer**: write or improve the Jekyll theme code
In any case is very important to know:
* If you push directly to `production` is almost you will mess up the repository.
* Setup proposed above avoid this to happen.
* **Only merge to `production` from `master`**. Otherwise you will mess up the repository.
* `Warning` Be extremely carrefull while merging to `production`.
* There is no way to avoid this via configurtion. Again, be atentive while merging to `production`.
* If you are content developer try to always work (add commits) directly in the `master` branch
* If you are theme developer then you must to create a feature branch, to deliver your work you propose a Merge to `master` (**never** to `production`).
### Workflow Content Developer
* Go to main project in gitlab
* Modify the website content
* Commit (Save) your changes in the default branch (`master`)
* Wait 2 to 5 minutes (check Gitlab CI/CD pipeline for details)
* Check your changes in the preproduction environment domain (ex: pre-subdomain.example.com)
* If you think is good then:
* If you have a reviewer (ex: the project manager) create a Merge Request and made him the owner for the MR and ask him to check ASAP
* If good he supposed to merge your content to `production` and by doing that your changes will be deployed in production.
* If changes are required your reviewer supposed to write comments in the MR sugesting changes or pointing problems.
### Workflow Theme Developer
* Go to main project in gitlab and copy the link to clone it
* Clone main project (`master` default branch.
* Checkout a new branch (other that `master` or `production`) by example `git checkout -b TRI-feature-name`
* Push your feature branch to our GitLab
* While ready do a MR from your feature branch (ex: `TRI-feature-name`) to `master` and assign it to the project manager.
### Workflow Project Manager
Any branch other that `master` or `production` is considered a feature branch.
* You must to review the Merge Request, your main mission is to ensure:
* Theme Developers propose MR from their own feature branch to `master` branch
* Almost inmediatly merge (do a MR and then merge it yourself) this changes to `production`
* Content Developers propose MR from `master` to `production`
* You also suposed to take a look to the code (both real code and content) to ensure things are OK and you also supposed to check the preproduction website (validate *pre-subdomain.example.com/commit.hml* to know wich commit you are reviewing) to validate that it works as expected.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment