Gearstock

Mergify Status

Technical documentation

See User documentation: USER.md

Document Version: 1.2 (28.02.2020 - DD/MM/YYYY)

Author: Valentin Lebon (valentin.lebon@epitech.eu)

Table of Contents

Documentation

1. Dependences

You need Docker installed with docker-compose.

2. Containerisation with Docker

See Docker official documentation.

See Docker Compose official documentation.

Services are describes in the docker-compose.yml file.

3. Build and launch Application

To build and launch the application, first check if the database/secrets.env file exist (see 6. Changing MongoDB's admin's password). Then, open a console/terminal and execute the following command in the root directory of this application.

docker-compose up --build -d

4. Update application

All commands in this part have to be executed in the root directory of this application.

1. Changing docker-compose.yml or a Dockerfile file

When changing the docker configuration, you'll have to execute:

docker-compose up -d --build

2. Changing certbot's configuration

To change cerbot (SSL) configuration, you'll have to change the Dockerfile in cerbot directory, then take a look at Changing a Dockerfile file.

3. Changing apache's configuration

When changing the apache configuration (under apache/conf directory), you'll have to exectute:

docker-compose stop apache && docker-compose up --build -d apache

4. Updating website

If you want to update the website, you'll need to execute the command below, then wait for it to finish.

docker-compose up front

5. Updating API

If you want to update the API, you'll need to execute this command:

docker-compose stop api && docker-compose up api_builder && docker-compose up -d api

6. Changing MongoDB's admin's password

To change the admin's password of the MongoDB database, you'll have to change the MONGO_INITDB_ROOT_PASSWORD value in database/secrets.env. If this file doesn't exit, create it.

To change the admin's username of the MongoDB database, you'll have to change the MONGO_INITDB_ROOT_USERNAME value in database/secrets.env. If this file doesn't exit, create it.

7. Pipelines and pull requests

Gearstock's project's deployment's automation is taking place in two environments: Dev and Prod, each hosted on an Azure VM.

1. The Dev environment

The Dev environment's purpose is to test together all the resources from the diferents branches to handle and correct (on those branches and NOT on dev branch) bugs and defects before uploading the resources to the Prod environment.

When a pull request is made to the dev branch, a pipeline is triggered. This pipeline will run tests on a separated environment, where the acceptance of the pull request is simulated.

If all the tests succeed, the pull request is accepted and the resulted resources are updated to the dev branch and then to the Dev environment.

2. The Prod environment

The Prod environment's purpose is to provide the Gearstock's project to the final users.

When a pull request is made from the dev branch to the master branch, a pipeline is triggered. This pipeline will run tests on a separated environment, where the acceptance of the pull request is simulated.

If all the tests succeed, the pull request is accepted and the resulted resources are updated to the master branch and then to the Prod environment. The new version of the project is then available on Internet.

3. The pipelines' schem

Pipelines