diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 65 |
1 files changed, 43 insertions, 22 deletions
@@ -3,42 +3,63 @@ Small client-server application. The server receives a URL from a client and returns the appropriate page. -URIs (URLs) are in the form `userinfo@address:portPATH`, where `address` and `port` could be skipped. -The userinfo section is analogous to subdomains in normal web applications. +## DevOps lifecycle -It's assumed that all pages are written in Markdown so the client adds special "rendering" like hyperlinks and bold text (via ANSI escape sequences). -The server is configured to send pages only in allowed directories, and can handle multiple directories with custom error pages. +### 1. Plan -## From issue to production +With [GitHub issues](https://github.com/Syndamia/pico-web/issues) modifications to the project are started and discussed - +### 2. Code -1. A [GitHub issue](https://github.com/Syndamia/pico-web/issues) is created when something needs to be added/changed in the project -2. Then a developer makes the appropriate branch (which I call the "feature branch"), where they push updates to the codebase. - On every commit a small pipeline is ran, executing all tests and static analysis. -3. Upon completion, a merge request is made to the `dev` branch. After the GitHub workflow is successful and a mandatory review, it will be merged. -4. Then, on the new commit, a new workflow is started on the `dev` branch, doing again the tests and static analysis, alongside the security analysis. - Afterwards, the development binaries are built and the [development Docker image](https://hub.docker.com/r/syndamia/pico-web-dev) is deployed. -5. After enough changes have accumulated, another pull request is made, from `dev` to `main` (PRs to `main` are only done from `dev`). - On successful workflow and mandatory review, the changes can be merged. -6. Finally, a pipeline from the `main` branch will be ran, deploying the [production server Docker image](https://hub.docker.com/r/syndamia/pico-web-server) and creating a new GitHub release. +Our branching strategy is a "feature workflow with stable branches", meaning: -Although there is no deployment to a managed kubernetes cluster (too expensive), a Deployment with the [demo](./demo) files is available: +- a feature branch is created for each issue +- after the issue is resolved in that branch, it is merged into the `dev` branch +- after enough time has passed, the `dev` branch is merged into the `main` branch -```bash -kubectl apply -f demo-production-server-deployment.yaml -``` +You must only push commits to feature branches. +Code can be added to `dev` only via pull requests from feature branches. +Code can be added to `main` only via pull requests from `dev`. + +Merge requests must always be approved by a contributor and `dev` merge requests to `main` must always have one of these labels: `release:major`, `release:minor` or `release:patch`. + +### 3. CI + +On each push to feature branches and `dev` we execute the "feature-branch" pipeline, during which we run: + +- SAST: unit tests, [clang](TODO)'s `--analyze` static analysis and [flawfinder](TODO)'s security analysis <!-- and SonarCloud, Trivy --> +<!-- +- SCA: https://github.com/multilang-depends/depends +--> +- the `Makefile` for building our application -## Building and usage +### 4. CD -Build the binaries: +On each successful merge request to `dev`, + +- a development docker image is deployed to [dockerhub](https://hub.docker.com/r/syndamia/pico-web-dev) and +- the development Kubernetes cluster is deployed with [minikube](TODO) in the pipeline + +On each successful merge request to `main`, + +- the production docker image is deployed to [dockerhub](https://hub.docker.com/r/syndamia/pico-web), +- the production Kubernetes cluster is deployed with [minkube](TODO) in the pipeline and +- a [GitHub release](https://github.com/Syndamia/pico-web/releases) is created, according to the pull request label ```bash -make +kubectl apply -f demo-production-server-deployment.yaml ``` +## Project details + You get two binaries, `server` and `browser`. +URIs (URLs) are in the form `userinfo@address:portPATH`, where `address` and `port` could be skipped. +The userinfo section is analogous to subdomains in normal web applications. + +It's assumed that all pages are written in Markdown so the client adds special "rendering" like hyperlinks and bold text (via ANSI escape sequences). +The server is configured to send pages only in allowed directories, and can handle multiple directories with custom error pages. + ### Browser The `browser` program takes no arguments. |