feat: Improve add-deployment Command Tests and Coverage

docs/ADRs/006-helm-style-logging.md

@@ -31,6 +31,12 @@ class HelmLogger:
         if args:
             msg = msg % args
         print("Error: %s" % msg, file=sys.stderr)
+
+    @staticmethod
+    def warning(msg: str, *args: Any) -> None:
+        if args:
+            msg = msg % args
+        print("Warning: %s" % msg, file=sys.stderr)
 ```
 
 ### 2. Key Design Decisions
@@ -39,6 +45,7 @@ class HelmLogger:
    - Use stderr for all output
    - Prefix debug messages with "[debug]"
    - Prefix error messages with "Error:"
+   - Prefix warning messages with "Warning:"
    - Control debug output via HELM_DEBUG environment variable
 
 2. **Performance Optimization**
@@ -67,6 +74,7 @@ def some_function():
         logger.debug("Success!")
     except Exception as e:
         logger.error("Failed: %s", str(e))
+    logger.warning("Something unexpected happened")
 ```
 
 ## Consequences
@@ -95,7 +103,7 @@ def some_function():
 ### Negative
 1. **Limited Flexibility**
    - Fixed output format
-   - No log levels beyond debug/error
+   - Limited log levels (debug/warning/error)
    - No log file support
 
 2. **Global State**
@@ -113,6 +121,12 @@ def test_debug_output():
          mock.patch('helm_values_manager.utils.logger.sys.stderr', stderr):
         logger.debug("Test message")
         assert stderr.getvalue() == "[debug] Test message\n"
+
+def test_warning_output():
+    stderr = StringIO()
+    with mock.patch('helm_values_manager.utils.logger.sys.stderr', stderr):
+        logger.warning("Test warning")
+        assert stderr.getvalue() == "Warning: Test warning\n"
 ```
 
 2. **Integration**
@@ -122,4 +136,5 @@ def validate(self):
     logger.debug("Validating PathData for path: %s", self.path)
     if not self.is_valid():
         logger.error("Invalid PathData: %s", self.path)
+    logger.warning("PathData validation completed with warnings")
 ```

docs/ADRs/011-command-structure-for-deployments.md

@@ -0,0 +1,83 @@
+# ADR-011: Command Structure for Deployments and Backends
+
+Date: 2025-02-28
+
+## Status
+
+Accepted
+
+## Context
+
+The Helm Values Manager needs to support multiple backend types (git-secret, aws, azure, gcp) and authentication methods (env, file, direct, managed_identity) for storing and retrieving values. The current implementation uses a single `add-deployment` command with many parameters, which can be complex and difficult to use.
+
+As we implement more backend types and authentication methods, the command structure needs to be intuitive, discoverable, and maintainable. The command interface should guide users to provide the correct parameters for each backend and authentication type.
+
+## Decision
+
+We will adopt a nested subcommand structure for deployment and backend management with the following pattern:
+
+```
+helm values add-deployment [name]
+
+helm values add-backend [backend] --deployment=[name] [backend_options]
+  - helm values add-backend aws --deployment=prod --region=us-west-2
+  - helm values add-backend azure --deployment=prod --vault-url=https://myvault.vault.azure.net
+  - helm values add-backend gcp --deployment=prod --project-id=my-project
+  - helm values add-backend git-secret --deployment=prod
+```
+
+Initially, deployments will be created with a `no-backend` type and `no-auth` authentication, indicating that they don't have a backend or authentication configured yet. This allows for deployments that might not need sensitive values, while providing a clear path to add a backend later if needed.
+
+For authentication, we will use a similar pattern:
+
+```
+helm values add-auth [auth_type] --deployment=[name] [auth_options]
+  - helm values add-auth direct --deployment=prod --credentials='{...}'
+  - helm values add-auth env --deployment=prod --env-prefix=AWS_
+  - helm values add-auth file --deployment=prod --auth-path=~/.aws/credentials
+  - helm values add-auth managed-identity --deployment=prod
+```
+
+This approach:
+1. Separates the concerns of creating a deployment, configuring a backend, and setting up authentication
+2. Uses subcommands to provide context-specific options and help text
+3. Follows a natural workflow of first creating a deployment, then adding backend and auth configuration
+4. Supports deployments without sensitive values through the `no-backend` option
+
+For the initial implementation, we will only implement the `add-deployment` command, with the backend and auth commands to be implemented later.
+
+## Consequences
+
+### Positive
+
+- **Improved User Experience**: Users only see options relevant to their current task
+- **Better Discoverability**: Each subcommand can have its own help text explaining the specific options
+- **Progressive Disclosure**: Complex options are only shown when needed
+- **Reduced Cognitive Load**: Users don't need to remember all possible combinations of options
+- **Better Validation**: Each command can validate its specific inputs more effectively
+- **Maintainability**: New backend types and auth methods can be added without changing existing commands
+- **Flexibility**: Users can create deployments without immediately configuring backends, allowing for more flexible workflows
+- **Safety**: The `no-backend` option provides a clear indication that a deployment is not configured for sensitive values, and validation can prevent adding sensitive values to such deployments
+
+### Negative
+
+- **More Commands**: Users need to run multiple commands to fully configure a deployment
+- **Learning Curve**: Users need to learn the command structure and workflow
+- **Implementation Complexity**: More commands means more code to maintain
+
+### Neutral
+
+- **Alignment with Other Tools**: This approach is similar to other CLI tools like `git` and `kubectl`
+- **Documentation Requirements**: We will need to document the command workflow clearly
+
+## Implementation Notes
+
+1. For the initial implementation, we will only implement the `add-deployment` command, which will create a deployment with minimal configuration.
+2. The `add-deployment` command will validate that the deployment name is unique and create a basic deployment entry in the configuration.
+3. The backend and auth commands will be implemented later, with appropriate validation to ensure that the referenced deployment exists.
+4. We will use Typer's nested command structure to implement this design.
+5. The `Deployment` class will need to support a "partial" state where backend and auth configuration may not be fully defined yet.
+
+## Related Issues
+
+- GitHub Issue #[TBD]: Implement command structure for deployments and backends

docs/ADRs/README.md

@@ -78,3 +78,10 @@ For new ADRs, use the [ADR template](adr-template.md) as a starting point.
 - **Decision**: Implement configuration comparison and smart merging with multiple strategies
 - **Impact**: Simplifies configuration updates and reduces risk of missing required changes
 - **Dependencies**: ADR-001
+
+### [ADR-011: Command Structure for Deployments and Backends](011-command-structure-for-deployments.md)
+- **Status**: Accepted
+- **Context**: Need for intuitive command structure for managing deployments with multiple backends and auth types
+- **Decision**: Implement nested subcommand structure for deployment, backend, and auth configuration
+- **Impact**: Improves user experience, discoverability, and maintainability
+- **Dependencies**: ADR-001

docs/Design/backends-and-auth.md

@@ -0,0 +1,188 @@
+# Backends and Authentication Types
+
+This document provides a comprehensive overview of the supported backends, authentication types, and backend configurations in the Helm Values Manager.
+
+## Supported Backends
+
+The Helm Values Manager supports the following backend types for storing values:
+
+| Backend Type | Description | Use Case | Status |
+|--------------|-------------|----------|--------|
+| `git-secret` | Uses git-secret for encrypting sensitive values | Local development, small teams | Planned |
+| `aws` | Uses AWS Secrets Manager for storing sensitive values | AWS-based deployments | Planned |
+| `azure` | Uses Azure Key Vault for storing sensitive values | Azure-based deployments | Planned |
+| `gcp` | Uses Google Secret Manager for storing sensitive values | GCP-based deployments | Planned |
+
+### Backend Selection Criteria
+
+When selecting a backend, consider:
+
+1. **Security Requirements**: Different backends offer varying levels of security, audit capabilities, and compliance features.
+2. **Cloud Provider**: Select the backend that aligns with your cloud infrastructure.
+3. **Team Size**: For small teams, simpler backends like `git-secret` may be sufficient.
+4. **Operational Complexity**: Some backends require more setup and maintenance than others.
+
+## Authentication Types
+
+Each backend supports multiple authentication methods:
+
+| Auth Type | Description | Required Parameters | Supported Backends |
+|-----------|-------------|---------------------|-------------------|
+| `direct` | Direct credential input | `credentials` object | All |
+| `env` | Environment variable-based authentication | `env_prefix` | All |
+| `file` | File-based authentication | `path` to auth file | All |
+| `managed_identity` | Cloud provider managed identity | None | `aws`, `azure`, `gcp` |
+
+### Authentication Type Details
+
+#### Direct Authentication (`direct`)
+
+Credentials are provided directly in the configuration file. This is suitable for testing but not recommended for production use.
+
+**Required Parameters:**
+- `credentials`: An object containing backend-specific credentials
+
+**Example:**
+```json
+"auth": {
+  "type": "direct",
+  "credentials": {
+    "token": "your-token-here"
+  }
+}
+```
+
+#### Environment Variable Authentication (`env`)
+
+Credentials are read from environment variables. This is suitable for CI/CD pipelines and containerized deployments.
+
+**Required Parameters:**
+- `env_prefix`: Prefix for environment variables
+
+**Example:**
+```json
+"auth": {
+  "type": "env",
+  "env_prefix": "AWS_"
+}
+```
+
+#### File Authentication (`file`)
+
+Credentials are read from a file. This is suitable for local development and when credentials are managed by external systems.
+
+**Required Parameters:**
+- `path`: Path to the authentication file
+
+**Example:**
+```json
+"auth": {
+  "type": "file",
+  "path": "~/.aws/credentials"
+}
+```
+
+#### Managed Identity Authentication (`managed_identity`)
+
+Uses cloud provider's managed identity service. This is the recommended approach for production deployments in cloud environments.
+
+**Required Parameters:**
+- None
+
+**Example:**
+```json
+"auth": {
+  "type": "managed_identity"
+}
+```
+
+## Backend Configurations
+
+Each backend may require additional configuration parameters:
+
+### Git Secret Backend (`git-secret`)
+
+| Parameter | Description | Required | Default |
+|-----------|-------------|----------|---------|
+| None | No additional configuration required | - | - |
+
+### AWS Secrets Manager Backend (`aws`)
+
+| Parameter | Description | Required | Default |
+|-----------|-------------|----------|---------|
+| `region` | AWS region | Yes | - |
+| `prefix` | Prefix for secret names | No | Empty string |
+| `endpoint` | Custom endpoint URL | No | AWS default endpoint |
+
+**Example:**
+```json
+"backend_config": {
+  "region": "us-west-2",
+  "prefix": "myapp/"
+}
+```
+
+### Azure Key Vault Backend (`azure`)
+
+| Parameter | Description | Required | Default |
+|-----------|-------------|----------|---------|
+| `vault_url` | Key Vault URL | Yes | - |
+| `prefix` | Prefix for secret names | No | Empty string |
+
+**Example:**
+```json
+"backend_config": {
+  "vault_url": "https://myvault.vault.azure.net/",
+  "prefix": "myapp-"
+}
+```
+
+### Google Secret Manager Backend (`gcp`)
+
+| Parameter | Description | Required | Default |
+|-----------|-------------|----------|---------|
+| `project_id` | GCP Project ID | Yes | - |
+| `prefix` | Prefix for secret names | No | Empty string |
+
+**Example:**
+```json
+"backend_config": {
+  "project_id": "my-gcp-project",
+  "prefix": "myapp_"
+}
+```
+
+## Implementation Status
+
+For the MVP release, the following components are implemented:
+
+1. **Command Interface**:
+   - `add-deployment`: Command interface implemented
+   - Backend validation: Interface defined, implementation pending
+
+2. **Backends**:
+   - All backends: Interface defined, implementation pending
+
+3. **Authentication Types**:
+   - All auth types: Interface defined, implementation pending
+
+4. **Backend Configurations**:
+   - Basic validation implemented
+   - Backend-specific validation defined in the command interface
+
+## Future Enhancements
+
+1. **Additional Backends**:
+   - HashiCorp Vault
+   - Kubernetes Secrets
+   - Custom backends via plugins
+
+2. **Enhanced Authentication**:
+   - OIDC support
+   - Role-based access for cloud providers
+   - Multi-factor authentication integration
+
+3. **Configuration Extensions**:
+   - Rotation policies
+   - Versioning support
+   - Audit logging

docs/Design/low-level-design.md

@@ -174,6 +174,31 @@ Benefits:
 - Automatic file locking
 - Configuration backup support
 
+#### Command Structure for Deployments and Backends
+
+The command structure for managing deployments and backends follows a nested subcommand pattern (see [ADR-011](../ADRs/011-command-structure-for-deployments.md)):
+
+```
+helm values add-deployment [name]
+
+helm values add-backend [backend] --deployment=[name] [backend_options]
+  - helm values add-backend aws --deployment=prod --region=us-west-2
+  - helm values add-backend azure --deployment=prod --vault-url=https://myvault.vault.azure.net
+  - helm values add-backend gcp --deployment=prod --project-id=my-project
+  - helm values add-backend git-secret --deployment=prod
+
+helm values add-auth [auth_type] --deployment=[name] [auth_options]
+  - helm values add-auth direct --deployment=prod --credentials='{...}'
+  - helm values add-auth env --deployment=prod --env-prefix=AWS_
+  - helm values add-auth file --deployment=prod --auth-path=~/.aws/credentials
+  - helm values add-auth managed-identity --deployment=prod
+```
+
+This structure:
+- Separates the concerns of creating a deployment, configuring a backend, and setting up authentication
+- Uses subcommands to provide context-specific options and help text
+- Follows a natural workflow of first creating a deployment, then adding backend and auth configuration
+
 ### 4. Storage Backends
 
 The `ValueBackend` interface defines the contract for value storage:
@@ -202,6 +227,8 @@ Implementations:
 - Azure Key Vault Backend
 - Additional backends can be easily added
 
+For a comprehensive overview of supported backends, authentication types, and backend configurations, see [Backends and Authentication Types](backends-and-auth.md).
+
 ### 5. Schema Validation
 
 The configuration system uses JSON Schema validation to ensure data integrity and consistency: