* 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.
