Documentation and explanation.

README.md

 # Igentify assignment
+
+> Goal: Build a CI/CD pipeline.
+
+## Description
+
+I forked the Platform.sh example Django2 project. I then replaced the
+platform.sh specifics with a docker-compose setup (for local usage).
+Afterwards I added a Kubernetes deployment and a GitLab CI/CD pipeline.
+
+## Relevant files
+
+`Dockerfile`
+`docker-compose.yml`
+`.gitlab-ci.yml`
+`myapp-deployment.yaml`
+`myapp-migrate.yaml`
+
+## Pipeline
+
+The pipeline has 3 steps, build (and upload), test and deploy. The build step
+builds the image, tagged as the build run number and uploads it to the registry.
+The test step uses the image from the registry, runs it in a Docker network
+along side the services described in the step (postgres), runs the migration and
+then the tests (no tests so far). This way you always run with a clean database,
+test the migrations as well and you can run several such tests simultaneously,
+even on the same machine. The last step is deployment, which is run manually.
+The step downloads from an S3 bucket the kubectl config then runs the database
+migration job, waits for it to finish successfully and finally deploys the
+relevant version.
+
+## Assumptions
+
+- An S3 bucket with the `kubectl` config file for the Kubernetes cluster.
+- AWS key ID and secret for the IAM user that's allowed access to the S3 bucket
+  (key ID in `.gitlab-ci.yml` and the secret in the secret variables through the
+webui).
+- PostgresQL database deployed to the Kubernetes cluster.
+- Kubernetes secret for the postgres password.
+- GitLab Docker image registry.
+- GitLab runner with access to the Docker daemon.
+- Connectivity with Kubernetes cluster.
+
+## Further work
+
+- Running as a limited user insided the container.
+- Smaller image size.
+- Resource limits.
+- Spliting the upload for the `latest` from the build and upload, not uploading
+  if the test failed.
+- Use seperate Postgres accounts for migrations and the application.