refactor: Split large deployment.yaml template for better maintainability #33

New Issue

2026-02-22T13:11:18Z

cpfarhood commented

2026-02-22 13:11:18 +00:00

(Migrated from github.com)

Problem

The current deployment.yaml template is 306 lines long and complex, making it hard to maintain and understand. All MCP sidecars are defined inline, creating a monolithic template.

Proposed Solution

Split the deployment template into logical components:

chart/templates/
├── deployment-main.yaml          # Main container definition
├── deployment-sidecars.yaml      # All MCP sidecars
├── _sidecar-helpers.tpl          # Reusable sidecar templates
└── _validation-helpers.tpl       # Template validation functions

Implementation Details

1. Main Container Template

deployment-main.yaml - Core deployment with main container only

2. Sidecar Template

deployment-sidecars.yaml - Include all MCP sidecars using helpers

3. Reusable Helpers

_sidecar-helpers.tpl - Common patterns:

{{- define "antigravity.mcpSidecar" -}}
{{/* Reusable MCP sidecar template */}}
{{- end }}

{{- define "antigravity.sidecarResources" -}}
{{/* Common resource patterns */}}
{{- end }}

4. Validation Helpers

_validation-helpers.tpl - Input validation:

{{- define "antigravity.validateMcpConfig" -}}
{{/* Validate MCP sidecar configuration */}}
{{- end }}

Benefits

Maintainability: Easier to modify individual components
Readability: Clear separation of concerns
Reusability: Common patterns can be shared
Testing: Individual components can be tested
Debugging: Easier to troubleshoot specific sections

Implementation Plan

Create new template files with split components
Add reusable template helpers
Migrate existing deployment.yaml content
Add validation helpers
Test template rendering
Update documentation

## Problem The current `deployment.yaml` template is 306 lines long and complex, making it hard to maintain and understand. All MCP sidecars are defined inline, creating a monolithic template. ## Proposed Solution Split the deployment template into logical components: ``` chart/templates/ ├── deployment-main.yaml # Main container definition ├── deployment-sidecars.yaml # All MCP sidecars ├── _sidecar-helpers.tpl # Reusable sidecar templates └── _validation-helpers.tpl # Template validation functions ``` ## Implementation Details ### 1. Main Container Template **`deployment-main.yaml`** - Core deployment with main container only ### 2. Sidecar Template **`deployment-sidecars.yaml`** - Include all MCP sidecars using helpers ### 3. Reusable Helpers **`_sidecar-helpers.tpl`** - Common patterns: ```yaml {{- define "antigravity.mcpSidecar" -}} {{/* Reusable MCP sidecar template */}} {{- end }} {{- define "antigravity.sidecarResources" -}} {{/* Common resource patterns */}} {{- end }} ``` ### 4. Validation Helpers **`_validation-helpers.tpl`** - Input validation: ```yaml {{- define "antigravity.validateMcpConfig" -}} {{/* Validate MCP sidecar configuration */}} {{- end }} ``` ## Benefits - **Maintainability**: Easier to modify individual components - **Readability**: Clear separation of concerns - **Reusability**: Common patterns can be shared - **Testing**: Individual components can be tested - **Debugging**: Easier to troubleshoot specific sections ## Implementation Plan - [ ] Create new template files with split components - [ ] Add reusable template helpers - [ ] Migrate existing deployment.yaml content - [ ] Add validation helpers - [ ] Test template rendering - [ ] Update documentation

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: farhoodlabs/devcontainer#33