59 lines
2.2 KiB
Markdown
59 lines
2.2 KiB
Markdown
# Inviscid
|
|
|
|
Inviscid is a proposed startup that helps small businesses monitor the health
|
|
and performance of their web applications. Customers would use a dashboard to
|
|
see availability, response times, request volume, and error rates, paired with
|
|
plain-language status summaries such as "Your website is responding slowly."
|
|
|
|
The semester prototype targets one demonstration customer application, building
|
|
on the team's existing Node.js website. Monitoring, the dashboard,
|
|
and deployment automation are **planned work, not completed features**. See the
|
|
Project Proposal chapter of the manual for the full plan and the Prometheus vs.
|
|
VictoriaMetrics comparison.
|
|
|
|
## Repository contents
|
|
|
|
| Path | Contents |
|
|
|---|---|
|
|
| `devopsAssignment.tex`, `chapters/`, `frontmatter/`, `backmatter/`, `figures/` | The team's LaTeX DevOps IT manual (SSW 590) |
|
|
| `docker/gitea/` | Versioned deployment files for the Gitea work hub (Compose, Caddyfile, deployment README) |
|
|
| `docker/color-buttons/` | Color Buttons demonstration app (Node.js/Express, Dockerfile) |
|
|
| `docker/latex-compiler/` | Docker image for compiling the manual |
|
|
|
|
## Links
|
|
|
|
- Gitea work hub: <https://git.inviscid.dev/>
|
|
- This repository: <https://git.inviscid.dev/Inviscid/SSW590-DevOps>
|
|
- Deployment documentation: [`docker/gitea/README.md`](docker/gitea/README.md)
|
|
|
|
## Building the manual
|
|
|
|
The manual uses `minted`, which needs shell escape and the `latexminted`
|
|
helper. Overleaf compiles it as-is. Locally:
|
|
|
|
```sh
|
|
latexmk -pdf devopsAssignment.tex
|
|
```
|
|
|
|
`latexmkrc` enables `-shell-escape` and runs `makeglossaries` automatically.
|
|
|
|
## Team
|
|
|
|
| Member | Gitea account | Role |
|
|
|---|---|---|
|
|
| Victor | `victor` | Organization owner; site administrator; domain, DNS, and Gitea deployment |
|
|
| Payton | `payton` | Organization owner; HTTPS, firewall, persistence testing, repository workflow |
|
|
|
|
## Workflow
|
|
|
|
1. Open an issue with a short description and acceptance criteria.
|
|
2. Create a branch from `main`.
|
|
3. Open a pull request into `main` and reference the issue with `Closes #N`.
|
|
4. Request a review from the other team member; merge only after approval.
|
|
5. Confirm the linked issue closed.
|
|
|
|
## Secrets
|
|
|
|
Never commit passwords, tokens, private keys, `app.ini`, database files, or
|
|
volume contents. The manual's Passwords table contains hints only.
|