ditkrg/guidelines-and-instructions
4
0
Fork 0
mirror of https://github.com/ditkrg/guidelines-and-instructions.git synced 2026-01-22 22:06:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #5 from ditkrg/general_review

Browse Source 
First review
This commit is contained in:
Brusk Hamarash 2021-11-01 14:54:13 +03:00 committed by GitHub
commit 71c3fcf14a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 38 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
Software-Development/README.md
View File

@ -19,7 +19,7 @@
| Reviewer | Date of Review | | Reviewer | Date of Review |
| -------------------- | ---------------- | | -------------------- | ---------------- |
| [Reviewer Name Here] | [Date of Review] | | Shkar T. Noori | October 10, 2021 |
@ -189,7 +189,7 @@ All software code bases must have a branch named `main` that acts as the default
##### Branching ##### Branching
Conventionally, each code base must also have a branch that corresponds to an identical deployment environment. For example, the branch `dev` corresponds to codes running in an `dev` environment, `staging` to `staging`, `pre-prod` to `pre-prod`, and `main` to`production`. Conventionally, each code base must also have a branch that corresponds to an identical deployment environment. For example, the branch `dev` corresponds to codes running in a `dev` environment, `staging` to `staging`, `pre-prod` to `pre-prod`, and `main` to `production`.
All code bases must have a branch that corresponds to a major version. For example branch `v1.x.x` must contain all initial codes. The next major release must also get its own branch `v2.x.x` which is typically created off `main`. (Edge cases must be explicitly authorized by the Head of Digital Development or DevOps). All code bases must have a branch that corresponds to a major version. For example branch `v1.x.x` must contain all initial codes. The next major release must also get its own branch `v2.x.x` which is typically created off `main`. (Edge cases must be explicitly authorized by the Head of Digital Development or DevOps).
@ -211,7 +211,7 @@ From `main` create `v2.x.x` -> `dev` -> `staging` -> `pre-prod` -> `main`
##### Merging and Pushing ##### Merging and Pushing
All developers are free to push to the release branch and `dev` whenever they would like to. However, pushing to any branch other branch requires a Pull Request that needs review and approval. All developers are free to push to the release branch and `dev` whenever they would like to. However, pushing to any other branch requires a Pull Request that needs review and approval.
Below is an overview of the policies: Below is an overview of the policies:
@ -248,7 +248,7 @@ If it is absolutely necessary to avoid conforming to the principles of this sect
### Deployment Strategy ### Deployment Strategy
All software at DIT is deployed using Docker and will be running on Kubernetes. That being said, each piece of software must contain these valid documents: All software at DIT is packaged using Docker and will be running on Kubernetes. That being said, each piece of software must contain these valid documents:
1. Dockerfile: Specifies instructions of how to build the docker image for the software. 1. Dockerfile: Specifies instructions of how to build the docker image for the software.
2. .dockerignore: Specifies which files must be ignored when building the docker image. 2. .dockerignore: Specifies which files must be ignored when building the docker image.
@ -259,7 +259,7 @@ All software at DIT is deployed using Docker and will be running on Kubernetes.
The Dockerfile is a standard file that gives out instruction on how to build an image for the source code. Diffberent technology stacks have different base images on the top of which the new image is built. DIT has a local registry for all needed images. The base images used in this Dockerfile must be coming from our local registry. If the on-prem registry does not contain the base images that you need, speak to the Head of DevOps so that they are made available. If it is absolutely necessary to use an image that for some reasons cannot be hosted on our local registry, speak to the Head of DevOps to obtain approval. Otherwise, the change is considered a bug. The Dockerfile is a standard file that gives out instruction on how to build an image for the source code. Diffberent technology stacks have different base images on the top of which the new image is built. DIT has a local registry for all needed images. The base images used in this Dockerfile must be coming from our local registry. If the on-prem registry does not contain the base images that you need, speak to the Head of DevOps so that they are made available. If it is absolutely necessary to use an image that for some reasons cannot be hosted on our local registry, speak to the Head of DevOps to obtain approval. Otherwise, the change is considered a bug.
See also: [Dockerfile reference](https://docs.docker.com/engine/reference/builder/)
##### Docker Layer Caching ##### Docker Layer Caching
@ -272,34 +272,27 @@ Docker Layer Caching mainly works on `RUN`, `COPY` and `ADD` commands.
Image layers in the Dockerfile must be properly cached and necessary techniques to invalidate the cache must be put in place. Here is an example of how caching the layers could be achieved: Image layers in the Dockerfile must be properly cached and necessary techniques to invalidate the cache must be put in place. Here is an example of how caching the layers could be achieved:
```dockerfile ```dockerfile
FROM reg.dev.krd/phusion/passenger-full:1.0.14 AS base FROM reg.dev.krd/library/ubuntu:20.04 AS base
ENV HOME /root
CMD ["/sbin/my_init"]
ADD nginx.conf /etc/nginx/sites-enabled/webapp.conf
RUN rm -f /etc/service/nginx/down
RUN rm /etc/nginx/sites-enabled/default
RUN mkdir /home/app/webapp
RUN nginx -t
COPY file.txt /target.txt
RUN apt-get update -qq && apt-get install -y postgresql-client RUN apt-get update -qq && apt-get install -y postgresql-client
RUN gem install bundler -v 2.2.17
FROM base as installation
ENV BUNDLER_VERSION=2.2.17
``` ```
In this example, when building the dockerfile, any changes to the `file.txt` will result in reinstalling the dependencies; which is most likely not what we want. we can fix that by simply moving the copy command below the run command:
```dockerfile
FROM reg.dev.krd/library/ubuntu:20.04 AS base
RUN apt-get update -qq && apt-get install -y postgresql-client
COPY file.txt /target.txt
```
This way, even when we make changes to the `file.txt`, we do not have to reinstall the dependencies.
We also recommend reading the official [Best practices for writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/). We also recommend reading the official [Best practices for writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/).
### Statelessness ### Statelessness
Distributed applications must maintain statelessness all during its life cycle. This is a founding principle of all distributed systems. Distributed applications must maintain statelessness all during its life cycle. This is a founding principle of all distributed systems.
@ -326,7 +319,14 @@ When using sticky sessions, please speak to the Head of DevOps to obtain approva
#### Storage #### Storage
In a distributed system, files must not be stored locally on the host machine. Rather, a storage service must be used. DIT provides a on-prem, S3-compatible blob storage service. Please speak to the Head of DevOps to obtain the necessary information in this regard. In a distributed system, files must not be stored locally on the host machine. Rather, a storage service must be used.
The supported storage services:
1. DIT provides an on-prem, S3-compatible blob storage service.
2. Persistent volumes can be attached to running containers (Only When Required).
Please speak to the Head of DevOps to obtain the necessary information in this regard.
### Race Condition ### Race Condition
@ -437,6 +437,16 @@ All web application are required to provide a `GET /status` endpoint with a simi
} }
``` ```
Example:
```json
{
"name":"simple-api",
"version":"0.1.0",
"startTime":"2021-10-28T14:49:08.06+00:00",
"host":"simple-api-deployment-c99cdcfdf-xrfh4"
}
```
## Software Application Specifications ## Software Application Specifications
@ -447,9 +457,9 @@ Unless specified explicitly per project, all applications that need to use an au
#### URLs #### URLs
Use `https://auth.dev.krd` in `dev`, `staging`, and `pre-prod` environment. Use __https://auth.dev.krd__ in `dev`, `staging`, and `pre-prod` environment.
Use `https://account.id.krd` in production environment. Use __https://account.id.krd__ in production environment.
#### OpenID Connect #### OpenID Connect
@ -503,9 +513,9 @@ For that, applications may request to search in the CAS in order to on-board use
###### URLs ###### URLs
Use `https://api.auth.dev.krd` in `dev`, `staging`, and `pre-prod` environment. Use __https://api.auth.dev.krd__ in `dev`, `staging`, and `pre-prod` environment.
Use `https://api.account.id.krd` in production environment. Use __https://api.account.id.krd__ in production environment.
###### Authentication Flow ###### Authentication Flow