Update README.md - continuous integration

.github/workflows/ci.yml

@@ -13,7 +13,7 @@ jobs:
     name: Build Docker image and run end-to-end tests
     runs-on: ubuntu-latest
     steps:
-      - name: Checkout code from Github
+      - name: Checkout code from GitHub
         uses: actions/checkout@v3
       - name: Run end-to-end tests
         run: >

README.md

@@ -66,8 +66,8 @@ In this way you don't force `pytest` to be installed with main dependencies. You
 ## Static Code Analysis and Security Scanning
 
 This project uses [black](https://black.readthedocs.io/en/stable) to flag any formatting inconsistencies in your code,
-[isort](https://pycqa.github.io/isort)(seems not being actively maintained anymore) to ensure that your import statements stay organized according to the official recommendation, and
-[flake8](https://github.com/PyCQA/flake8)(seems not being actively maintained anymore) to check for any other PEP 8 style violations.
+[isort](https://pycqa.github.io/isort) (seems not being actively maintained anymore) to ensure that your import statements stay organized according to the official recommendation, and
+[flake8](https://github.com/PyCQA/flake8) (seems not being actively maintained anymore) to check for any other PEP 8 style violations.
 ```bash
 (.venv) $ python -m black src/
 (.venv) $ python -m isort src/
@@ -203,3 +203,47 @@ The command overwrite makes sure that we are using a production grade webserver
 - It will not handle more than one request at a time by default.
 - If you leave debug mode on and an error pops up, it opens up a shell that allows for arbitrary code to be executed on your server (think os.system('rm -rf /')).
 - The development server doesn't scale well.
+
+## Run End-to-End Tests
+
+The docker compose can be used to set up a test container for running the end-to-end test. The [profiles](https://docs.docker.com/compose/how-tos/profiles) can be used to mark the test container service:
+```yaml
+services:
+# ...
+
+  test:
+    profiles:
+      - testing  # This is a helpful feature
+    build:
+      context: ./web
+      dockerfile: Dockerfile.dev  # Dockerfile.dev bundles the testing framework
+    environment:
+      REDIS_URL: "redis://redis:6379"
+      FLASK_URL: "http://web:8000"
+    networks:
+      - backend-network
+    depends_on:
+      - redis
+      - web
+    command: >
+      sh -c 'python -m pytest test/e2e/ -vv
+      --redis-url $$REDIS_URL
+      --flask-url $$FLASK_URL'
+```
+
+## Define a Docker-Based Continuous Integration Pipeline
+
+Depending on your team structure, experience, and other factors, you can choose from different source control branching models, also known as [workflows](https://www.atlassian.com/git/tutorials/comparing-workflows).
+
+Once the code is hosted on git, [GitHub Actions](https://docs.github.com/en/actions) let you specify one or more workflows triggered by certain events, like pushing code to a branch or opening a new pull request. Each workflow can define a number of jobs consisting of steps, which will execute on a runner.
+Each step of a job is implemented by an action that can be either:
+- A custom shell command or a script
+- A GitHub Action defined in another GitHub repository
+
+In the [workflow CI file](./.github/workflows/ci.yml), we defined below four activities, which are quite self-explanatory
+- Checkout code from GitHub
+- Run end-to-end tests
+- Login to Docker Hub
+- Push image to Docker Hub
+
+And this completes this note.