In a fast-moving enterprise, platform engineering teams often find themselves in an uncomfortable role: the bottleneck.
As AI adoption surged, dozens of engineering teams across our company started building new microservices, AI agents, and tool connectors. Every team needed baseline cloud infrastructure:
- An isolated container registry with automated vulnerability scanning and retention policies.
- Dedicated encryption keys and secrets vaults.
- Identity roles with federated trust so automated CI/CD pipelines could push artifacts without long-lived static cloud credentials.
- GitOps manifests to deploy and run their services across cluster environments.
- Ingress routing, network firewall rules, and internal service discovery.
At first, teams submitted tickets. A platform engineer reviewed the ticket, wrote Infrastructure as Code by hand, opened a pull request, and ran the deployment.
When you have two new services a month, this is manageable. When you have multiple teams launching new AI agents and microservices every week, manual ticketing completely breaks down. Engineers wait weeks just to get a development environment up and running.
To solve this, we built a self-service IssueOps and GitOps onboarding engine.
What is IssueOps?
IssueOps is the practice of using issue-tracking systems (such as GitHub Issues or GitLab Issues) as the primary user interface for triggering operational and infrastructure automation.
Instead of writing and maintaining a custom internal web portal with bespoke user databases and authentication logic, developers interact with tools they already live in every day: structured issues, pull requests, and code review comments.
+-------------------------------------------------------------------------+
| The IssueOps Workflow |
| |
| 1. Developer submits a structured Service Onboarding Request |
| (Specifies service domain, workload type, and network exposure) |
| |
| 2. Automated Orchestration Pipeline triggers: |
| ├── Validates naming conventions, team ownership, and network tiers |
| ├── Generates Infrastructure as Code (registries, keys, roles) |
| ├── Generates GitOps deployment manifests (Helm / K8s specs) |
| └── Opens PRs against infrastructure and deployment repositories |
| |
| 3. Automated Policy & Approval Gates: |
| ├── Lower environments: Verified against policies and auto-applied |
| └── Production: Requires multi-team sign-off via issue comments |
| |
| 4. GitOps Operator synchronizes resources to the cluster automatically |
+------------------------------------------------------------------------+
1. Structured Declarative Request Templates
Free-form text tickets lead to endless back-and-forth communication. Developers forget to specify CPU requirements, omit ownership tags, or suggest invalid service names.
Instead, IssueOps uses declarative form templates. The form acts as a typed schema for infrastructure requests:
- Service Identifier: Enforces standard naming conventions via regex patterns.
- Workload Profile: Categorizes whether the workload is a long-running web API, an event-driven background worker, or a tool connector. This determines default autoscaling and memory limits.
- Network Exposure: Determines whether the service is internal to the service mesh or requires an external load balancer with web application firewall protection.
- Data Classification: Tags whether the service handles public or sensitive enterprise data, automatically attaching appropriate encryption and retention policies.
By validating constraints at submission time, the platform prevents invalid network configurations or naming collisions before any automation executes.
2. Automated Infrastructure Generation
Once a valid request is submitted, an automated workflow takes over. It translates the developer's inputs into declarative Infrastructure as Code (IaC) and GitOps configurations:
- Secure Container Registries: Automatically provisions a private image repository configured with automated vulnerability scanning and non-production image expiration policies.
- Dedicated Encryption Keys: Provisions a dedicated encryption key with least-privilege key policies granting access strictly to the service's runtime identity.
- Short-Lived Federated Identity: Configures an identity role with OpenID Connect (OIDC) federation, scoped strictly to the source repository and branch. CI/CD pipelines exchange short-lived tokens for temporary cloud access during build jobs. No developer or pipeline ever stores static, long-lived cloud keys.
- GitOps Deployment Manifests: Generates deployment definitions in the central GitOps repository, attaching standard enterprise base templates, health check probes, and pod disruption budgets.
By standardizing these patterns in code generators, every new service automatically complies with enterprise security and networking baselines on day one.
3. Governance and Approval Gates
Self-service does not mean an unmanaged free-for-all. Regulated enterprises require separation of duties and peer review.
IssueOps bridges self-service and compliance through automated approval gates:
- Non-Production Environments: If the request targets a development or scratch environment, automated linters verify policy compliance. If all checks pass, the system automatically merges the changes and provisions the environment in minutes.
- Production Environments: When a service is promoted to production, the automation tags designated review teams (such as the Service Owner, Platform Engineering, and Security) directly on the issue.
- Comment-Driven Approvals: Authorized leads review the generated plan and approve via structured comments. The automation verifies the reviewer's team membership and cryptographic signature before proceeding with the deployment.
This creates a complete, immutable audit trail. Every provisioned database, registry, and IAM role is linked directly to a Git commit and an approved issue thread.
4. Closing the Loop
Once the GitOps operator finishes synchronizing the service to the target cluster and health checks pass, the automation updates the original issue with service endpoints, connection guides, and status dashboards before closing it automatically.
Developers get an environment in minutes without waiting in ticketing queues, and platform engineers focus on building core platform capabilities instead of manually provisioning cloud resources.
Architectural Lessons
- Use existing developer workflows: Developers resist adopting new internal portals that require separate logins and unfamiliar UIs. Meeting developers where they already work—in their code forge and issue tracker—dramatically accelerates adoption.
- Security through automated baselines: When infrastructure provisioning is manual, teams cut corners to save time. When secure defaults (OIDC federation, KMS encryption, automated scanning) are generated automatically, security becomes the path of least resistance.
- Git as the single source of truth: Even though the workflow starts from an issue, all state lives in version-controlled Git repositories. This ensures that every change can be audited, reviewed, or rolled back using standard Git operations.
Top comments (0)