Nombre del proyecto

APP de Arquidiocesis de Monterrey

Table of contents

• Client Details
• Environment URLS
• Team
• Technology Stack
• Management Tools
• Setup the project
• Running the stack for development

Client Details

Name	Email	Role
Hector Ayala	[email protected]	CEO

Environment URLS

• Production - https://arquidiocesis-bda.herokuapp.com
• Development - N/A

Team

Name	Email	Role
César Barraza	[email protected]	Administración de la configuración
Daniel Gaytán	[email protected]	Product Owner Proxy
Patricio Saldivar	[email protected]	SCRUM Master / Líder
Martín Rivas	[email protected]	Administrador del Proyecto
Roberto Treviño	[email protected]	Development
Diego Martínez	[email protected]	Development
Fernando López	[email protected]	Development
Carlos Tamez	[email protected]	Development
Andrés Sánchez	[email protected]	Development
Carlos Miranda	[email protected]	Development
Gerardo Suarez	[email protected]	Development
Rolando Mata	[email protected]	Development

Technology Stack

Technology	Version
NodeJS	12.16.01
ExpressJS	04.17.01
Firebase	08.10.00

Management tools

You should ask for access to this tools if you don't have it already:

• Github repo
• Backlog
• Heroku
• Documentation (Microsoft Teams)

Development

Setup the project

Make sure the following tools are installed in your system:

• Node v12.X.X
• Yarn v1.21.X
• Git v2.X.X

1. Clone this repository into your local machine

$ git clone [email protected]:ProyectoIntegrador2018/arquidiocesis-back.git
$ cd arquidiocesis-back

2. Install the project dependencies

$ yarn install

Running the stack for Development

MacOS

1. Open a terminal and run:

$ export NODE_ENV=development

2. Add the file ServiceAccountKey.json which contains the Firebase credentials (ask to an admin)

3. Then run the project using

$ yarn run start:dev

That command will open the server on port 8000 by default.

Run unit and integration tests

In terminal or CLI run the following command:

$ yarn test

The command will do the following:

1. Present all unit and integration tests for components that are alive in the system.
2. Each unit test will appear with debug information and a green checkmark if it passed
3. Each component has a bunch of unit test and one integration test, the latest will be executed at the end.

Stop the project

To stop the application run control + C or command + C (mac) in the terminal.

Set your own port number

MacOS

1. Open the terminal and run:

$ export PORT=<your port number here>

Running the stack for Production

MacOS

1. Open terminal and run:

$ export NODE_ENV=production

2. Then run the project:

$ yarn run start

Documentation

All code is documented using jsdocs and should come included with the project, if not, read up the section below to generate documentation.

Navigate to docs folder and open index.html. This will open our documentaiton webpage.

Generating Documentation

We recommend VSCode for a better coding experience and giving the following plugins a try: HTML CSS Support Plugin by ecmel and HTML Preview by Thomas Haakon Townsend

To further develop, run the stack in development and run the command to generate the documentation:

yarn run docs

A new docs folder should have been created.

VSCode mac users run:

cmd-shift-v

VSCode windows users run:

ctrl-shift-v

this will open a new preview window, you can drag the pane to the side to preview changes as you develop the code.

Version control

Conventional commits

Commit messages are an essential part of software development because they allow us to communicate why our code changed.

To enforce a good convention is followed we're using Commitizen and Commitlint.

Commitizen is a command line utility that will prompt you to fill in any required fields (run with yarn commit) and your commit messages will be formatted according to the standards defined by project maintainers. In our case, we're using the conventional changelog standard with the following structure:

type(scope): subject

Commitlint is a linter for our commit messages and checks if they meet the conventional commit format.

Commitizen and commitlint will enforce we're creating conventional commit messages and, with the help of husky, they will prevent us from committing changes without the proper message structure.

Semantic release

One of the advantages of using the conventional commit format is that dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

Semantic release uses the commit messages to determine the type of changes in the codebase and automatically determines the next semantic version number, updates our version property in package.json, generates a changelog, commits the change and publishes the release to GitHub (both the commit and the release tag).

GitHub templates and workflows

To ensure a standard when creating Pull Requests or Issues (bug or feature request) we've included some templates inside the .github folder.

To automate the release of new versions we're using GitHub Actions to run the following workflows:

• Verify pull request base branch: Run when a pull request to the master branch is open. It will verify the base branch is dev and will fail if not the case.
• Set release version: Run when changes are pushed to master. It will run semantic-release and sync the master branch with dev. To enable this workflow in your repository add the GH_TOKEN secret based on a personal access token with repo scope.

To disable a given workflow simply remove the file.

Unit Testing Validations

To ensure that the changes made didn't affect the current funcionalities of the models run yarn test. This command will run all the tests and give the output of each individual test. In case of adding a new features, please add a test suite for each new module.