APP de Arquidiocesis de Monterrey
- Client Details
- Environment URLS
- Team
- Technology Stack
- Management Tools
- Setup the project
- Running the stack for development
| Name | Role | |
|---|---|---|
| Hector Ayala | ayalahector@hotmail.com | CEO |
- Production - https://arquidiocesis-bda.herokuapp.com
- Development - N/A
| Name | Role | |
|---|---|---|
| César Barraza | A01176786@itesm.mx | Administración de la configuración |
| Daniel Gaytán | A00819362@itesm.mx | Product Owner Proxy |
| Patricio Saldivar | A10282504@itesm.mx | SCRUM Master / Líder |
| Martín Rivas | A00818919@itesm.mx | Administrador del Proyecto |
| Roberto Treviño | A01282035@itesm.mx | Development |
| Diego Martínez | A01176489@itesm.mx | Development |
| Fernando López | A01172527@itesm.mx | Development |
| Carlos Tamez | A00817514@itesm.mx | Development |
| Andrés Sánchez | A00819118@itesm.mx | Development |
| Carlos Miranda | A00817390@itesm.mx | Development |
| Gerardo Suarez | A00817505@itesm.mx | Development |
| Rolando Mata | A00816442@itesm.mx | Development |
| Technology | Version |
|---|---|
| NodeJS | 12.16.01 |
| ExpressJS | 04.17.01 |
| Firebase | 08.10.00 |
You should ask for access to this tools if you don't have it already:
- Github repo
- Backlog
- Heroku
- Documentation (Microsoft Teams)
Make sure the following tools are installed in your system:
- Clone this repository into your local machine
$ git clone git@github.com:ProyectoIntegrador2018/arquidiocesis-back.git
$ cd arquidiocesis-back- Install the project dependencies
$ yarn install- Open a terminal and run:
$ export NODE_ENV=development-
Add the file
ServiceAccountKey.jsonwhich contains the Firebase credentials (ask to an admin) -
Then run the project using
$ yarn run start:devThat command will open the server on port 8000 by default.
In terminal or CLI run the following command:
$ yarn test
The command will do the following:
- Present all unit and integration tests for components that are alive in the system.
- Each unit test will appear with debug information and a green checkmark if it passed
- Each component has a bunch of unit test and one integration test, the latest will be executed at the end.
To stop the application run control + C or command + C (mac) in the terminal.
- Open the terminal and run:
$ export PORT=<your port number here>- Open terminal and run:
$ export NODE_ENV=production- Then run the project:
$ yarn run startAll 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.
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.
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.
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).
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
masterbranch is open. It will verify the base branch isdevand will fail if not the case. - Set release version: Run when changes are pushed to
master. It will runsemantic-releaseand sync themasterbranch withdev. To enable this workflow in your repository add theGH_TOKENsecret based on a personal access token with repo scope.
To disable a given workflow simply remove the file.
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.