Different environments serve different purposes in the life cycle of software development.


## Namespace management
Namespaces are a natural construct in Kubernetes to support environments. They allow dividing cluster resources among multiple teams or projects.

Kubernetes Namespace ~= Environment


## Git strategies
To implement GitOps, you should use a separate Git repository to hold your Kubernetes manifests (aka config), keeping the config separate from your application source code. Some props:
+ It provides a clean separation of application code and application config
+ Audit log is cleaner
+ Your application may comprise services built from multiple Git repositories but deployed as a single unit
+ Access is separated
+ If you are automating your CI pipeline, pushing manifest changes to the same Git repository can trigger an infinite loop of build jobs and Git commit triggers

For your code repositories, you can use whatever branching strategy you like (such as GitFlow). For your config repositories (which will be used for your CD), you need to consider the following strategies.

### Single branch (multiple directories)
There will be a default config for all environments with an environment-specific overlay defined in separate environment-specific directories.


The single-branch strategy can be easily supported by tools such as Kustomize. For example, we will have environment-specific override directories for qa, e2e, stage, and prod. Each directory will contain environment-specific settings such as replica count, CPU, and memory request/limit.

### Multiple branches
With the multiple-branches strategy, each branch is equivalent to an environment. The advantage here is that each branch will have the exact manifest for the environment without using any tool such as Kustomize. Each branch will also have a separate commit history for audit trail and rollback if needed.


The disadvantage is that there will be no sharing of the common config among environments.

### Multirepo vs. monorepo
If you are in a startup environment with a single scrum team, you may not want (or need) the complexity of multiple repositories. All your code could be in one repository.

However, if you are in an enterprise environment with dozens (or hundreds) of developers, you will likely want to have multiple repos so that teams can be decoupled from each other and each run at their own speed.


Another consideration for using multiple repos is to organize applications based on capabilities.

## Kubernetes config management tools
Good Kubernetes configuration tools have the following properties:
+ Declarative
+ Readable: easy to understand
+ Flexible: the tool helps facilitate
+ Maintainable

### Helm
The important thing to note about Helm is that it is a self-described package manager for Kubernetes and doesn’t claim to be a configuration management tool. However, since many people use Helm templating for precisely this purpose. These users end up maintaining several values.yaml, one for each environment (such as values-base.yaml, values-prod.yaml, and values-dev.yaml).

The good: highly reusable code.

The bad:
+ Go templating: readability problem
+ Complicated SaaS CD pipelines: chart parameters cannot support your desired manifest changes
+ Nondeclarative by default: for example use `--set param=value` to any one of your Helm deploys

### Jsonnet

local name = "nginx";
local version = "1.14.2";
local replicas = 2;
{
   "apiVersion": "apps/v1",
   "kind": "Deployment",
   "metadata": {
      "name": name
   },
   "spec": {
      "selector": {
         "matchLabels": {
            "app": name
         }
      },
      "replicas": replicas,
      "template": {
         "metadata": {
            "labels": {
               "app": name
            }
         },
         "spec": {
            "containers": [
               {
                  "name": name,
                  "image": "nginx:" + version,
                  "ports": [
                     {
                        "containerPort": 80
                     }
                  ]
               }
            ]
         }
      }
   }
}

### Features comparison


Flyway:Database migrations for deploy new version.