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.netlify.app/
• 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
Expo	36.00.00
ReactJS	16.9.0
React Native	00.61.04

Management tools

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

• Github repo
• Backlog
• Netlify
• 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-app.git
$ cd arquidiocesis-app

2. Install the project dependencies

$ yarn install

Running the stack for Development

1. Open a terminal and run

$ yarn run web

A web page will open and show the application running.

If you want to try the mobile version run

$ yarn run start

That command will open the Expo development server.

Once you are presented with a QR code, open up a mobile simulator either:

1. Using the presented options in the expo development server page
2. Using the Expo App on your phone and scanning the QR code.

Stop the project

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

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.

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.