docs: add profiles documentation

docs/pages/configuration/profiles/README.mdx

@@ -0,0 +1,96 @@
+---
+title: Config Profiles
+sidebar_label: Basics
+---
+
+import FragmentInfoPrintConfig from '../../_partials/tip-print-config.mdx';
+import FragmentApplyMultiple from '../../_partials/profiles-apply-multiple.mdx';
+
+DevSpace allows you to define different profiles for different use cases (e.g. working on different services in the same project, starting certain debugging environments) or for different deployment targets (e.g. dev, staging production). 
+
+Profiles allow you to define:
+- [`replace`](../../configuration/profiles/replace.mdx) statements to override entire sections of the config.
+- [`merge`](../../configuration/profiles/merge.mdx) patches ([JSON Merge Patch, RFC 7386](https://tools.ietf.org/html/rfc7386)) to change specific parts of the config.
+- [`patches`](../../configuration/profiles/patches.mdx) ([JSON Patch, RFC 6902](https://tools.ietf.org/html/rfc6902)) to modify certain paths in the config.
+
+:::note Combine several strategies
+It is possible to use several strategies together within one profile. The execution order inside a single profile is:  
+1. `replace`  
+2. `merge`  
+3. `patches`  
+
+You can also apply multiple profiles through the `--profile` flag
+:::
+
+:::tip Debug Profiles
+
+<FragmentInfoPrintConfig/>
+
+:::
+
+A profile has to be configured in the `profiles` section of the `devspace.yaml`.
+```yaml {15-25}
+images:
+  backend:
+    image: john/devbackend
+  backend-debugger:
+    image: john/debugger
+deployments:
+  backend:
+    helm:
+      values:
+        containers:
+        - image: john/devbackend
+        - image: john/debugger
+profiles:
+- name: production
+  patches:
+  - op: replace
+    path: images.backend.image
+    value: john/prodbackend
+  - op: remove
+    path: deployments.backend.helm.values.containers[1]
+  - op: add
+    path: deployments.backend.helm.values.containers
+    value:
+      image: john/cache
+```
+
+## Useful Commands
+
+### `devspace print -p [profile]`
+
+<FragmentInfoPrintConfig/>
+
+<FragmentApplyMultiple/>
+
+### `devspace list profiles`
+To get a list of available profiles, you can run this command:
+```bash
+devspace list profiles
+```
+
+### `devspace use profile [profile]`
+To permanently switch to a different profile, you can run this command:
+```bash
+devspace use profile [PROFILE_NAME]
+```
+
+:::note
+Permanently switching to a profile means that all future commands (e.g. `devspace deploy` or `devspace dev`) will be executed using this profile until the user [resets the profile](#devspace-use-profile---reset) (see below).
+:::
+
+### `devspace use profile --reset`
+To permanently switch back to the default configuration (no profile replaces and patches active), you can run this command:
+```bash
+devspace use profile --reset
+```
+
+### `devspace [deploy] -p [profile]`
+Most DevSpace commands support the `-p / --profile` flag. Using this flag, you can run a single command with a different profile without switching your profile permenantly:
+```bash
+devspace build -p [PROFILE_NAME]
+devspace deploy -p [PROFILE_NAME]
+devspace dev -p [PROFILE_NAME]
+devspace dev -i -p [PROFILE_NAME]
+```

docs/pages/configuration/profiles/activation.mdx

@@ -0,0 +1,117 @@
+---
+title: "Profiles: Activation"
+sidebar_label: activation
+---
+
+The `activation` option is optional and allows you to activate a profile using regular expression matching of either Devspace or environment variables. An activation is configured with the profile it activates in `devspace.yaml`.
+
+
+#### Example: Defining a Profile Activation using `vars`
+```yaml {1-3,7-8}
+vars:
+- name: ENV
+  default: development
+profiles:
+- name: production
+  activation:
+  - vars:
+      ENV: production
+  patches:
+  - op: replace
+    path: images.backend.image
+    value: john/prodbackend
+```
+The `production` profile would be activated when the Devspace variable `ENV` has value `production`.  In this example, it has a default value of `development`, so it is not activated unless you override the value using `--var ENV=production`
+
+#### Example: Defining a Profile Activation using Environment Variables
+```yaml {3-5}
+profiles:
+- name: production
+  activation:
+  - env:
+      ENV: "production"
+  patches:
+  - op: replace
+    path: images.backend.image
+    value: john/prodbackend
+```
+The `production` profile would be activated when the environment variable `ENV` has value `production`:
+
+#### Example: Regular Expression Activation
+```yaml {3-5}
+profiles:
+- name: production
+  activation:
+  - env:
+      ENV: "prod-\d+"
+  patches:
+  - op: replace
+    path: images.backend.image
+    value: john/prodbackend
+```
+The profile `production` would be activated when the environment variable `ENV` matches the regular expression `prod-\d+`. This can be useful for matching environment variables that have dynamic values. Regular expressions will have start of string (`^`) and end of string (`$`) anchors added automatically to avoid unexpected substring matching. 
+
+#### Example: Matching All
+When multiple `env` or `vars` name/expression pairs are specified in the same activation, all expressions must match to activate the profile. For example, the `production` profile is activated when the environment variable `CI` is `true` and the Devspace variable `ENV` is `development`:
+```yaml {3-7}
+profiles:
+- name: production
+  activation:
+  - env:
+      CI: "true"
+    vars:
+      ENV: "development"
+  patches:
+  - op: replace
+    path: images.backend.image
+    value: john/devbackend
+```
+
+:::note Combining `env` and `vars`
+While possible to activate profiles using environment variables and Devspace variables, `vars` can also be populated through environment variables. In the above example, we could have also defined `CI` as a Devspace variable with `source: env` and only used `vars` in the activation.
+:::
+
+#### Example: Matching Any
+When `env` or `vars` are used in multiple activations, the profile is activated when any expression matches. In this example, the `production` profile is activated when either match their expressions:
+```yaml {3-7}
+profiles:
+- name: production
+  activation:
+  - env:
+      CI: "true"
+  - vars:
+      ENV: "development"
+  patches:
+  - op: replace
+    path: images.backend.image
+    value: john/devbackend
+```
+
+### Dependency Activations
+When `dependencies` are referenced from a `devspace.yaml`, the dependency's profile activations will also be evaluated. In this example, any profile activations in `./component-1/devspace.yaml` or `./component-2/devspace.yaml` would be evaluated.
+
+```yaml
+dependencies:
+- name: component-1
+  source:
+    path: ./component-1
+- name: component-2
+  source:
+    path: ./component-2
+```
+
+#### Example: Disable Activations by Dependency
+The `disableProfileActivation` option can be used to disable profile activations for specific dependencies. In the following example, the activations for `./component-1/devspace.yaml` would be ignored, while the activations in `./component-2/devspace.yaml` would be evaluated:
+```yaml {5}
+dependencies:
+- name: component-1
+  source:
+    path: ./component-1
+  disableProfileActivation: true
+- name: component-2
+  source:
+    path: ./component-2
+```
+
+### Disable Activations Globally
+The `--disable-profile-activation` flag can be used to disable all profile activations, including those specifed within each dependency's `devspace.yaml`.

docs/pages/configuration/profiles/merge.mdx

@@ -0,0 +1,62 @@
+---
+title: "Profiles: Merge"
+sidebar_label: merge
+---
+
+Merge patches are a way to perform specific overrides to the configuration without having to create a completely separate config file. Patch functionality follows [JSON Merge Patch, RFC 7386](https://tools.ietf.org/html/rfc7386) semantics.
+
+### Example
+
+Merge patches are ideal for reflecting changes between different environments, e.g. dev, staging and production.
+```yaml {16-30}
+images:
+  backend:
+    image: john/devbackend
+  backend-debugger:
+    image: john/debugger
+deployments:
+  backend:
+    helm:
+      values:
+        containers:
+        - image: john/devbackend
+        - image: john/debugger
+profiles:
+- name: production
+  merge:
+    images:
+      # Change the backend image
+      backend:
+        image: john/prodbackend
+      # Delete the backend-debugger image
+      backend-debugger: null
+    # Override deployments
+    deployments:
+      backend:
+        helm:
+           values:
+             containers:
+             - image: john/prodbackend
+```
+**Explanation:**  
+- The above example defines 1 profile: `production`
+- When using the profile `production`, the config is merged with the given merge patch at `profiles[0].merge`.
+- Merge patches follow the rules as defined in [JSON Merge Patch, RFC 7386](https://tools.ietf.org/html/rfc7386):
+  - Arrays are overridden
+  - Objects are merged together
+  - Keys that have a `null` value are removed from objects
+- The resulting config used in-memory when the profile `production` is used would look like this (you can check via `devspace print -p production`):
+
+```yaml
+# In-Memory Config After Applying Merge Patches For Profile `production`
+images:
+  backend:
+    image: john/prodbackend
+deployments:
+  backend:
+    helm:
+      values:
+        containers:
+          - image: john/prodbackend
+```
+