GitOps: ITSM tools are not DevOps tools

A bit of a high level design rant, so pardon the fluff.

Problem: ITSM Tools Often Block Iteration Speed

A typical AWS Landing Zone workflow:

  • User submit requests through ServiceNow for account access

  • The Catalog Item (ServiceNow request form) is not that great and tricky to use

  • Approvals may take days

  • Once approved, the DevOps pipeline is triggered, but because of hardship with creating sensible API calls between an ITSM system and a DevOps tool, it’s harder to sanitize the data, making the run more error prone

  • The user is presented with 200 lines of different logs after days of waiting

Additional problems with above workflow

  • DevOps teams struggle with improving the workflow due to a overworked ITSM team faced with compliance and audit requirements

  • The actual provisioning happens outside ITSM and the response messages are not that great (formating is hard to do right here)

  • The DevOps engineer tasked with this work is usually not stoked about doing it

The core issue: ITSM tools are good at simple CRUD operations, but most of them are not DevOps tools.

Solution: Onboard the user to GitHub

Use ITSM tools for what they’re good at (access requests and compliance) while letting GitHub handle the DevOps pipeline.

Phase 1: ITSM tool Manages Repository Access

Developers request access to the infrastructure provisioning repository through standard ITSM processes:

  1. ServiceNow Request: “Access to aws-account-factory GitHub repository”
  2. Justification: “Need development environment for ML project”
  3. Approval Chain: Manager → Security → Infrastructure Team

Once approved, developers receive:

  • GitHub repository access
  • Documentation on account request process
  • YAML templates for their specific use case

Phase 2: GitHub Handles Technical Implementation

With repository access granted, the user creates a PR with an edited .yaml template, and the feedback loop can begin (Dev + Ops).

# accounts/engineering/ml-project-dev.yaml
account_name: "ml-project-development"
environment: "development"
cost_center: "engineering"
team_lead: "sarah@company.com"
compliance_level: "standard"

Phase 3: GitHub PR Drives the Workflow

The pull request becomes the technical collaboration space:

# .github/CODEOWNERS
accounts/engineering/* @infrastructure-team @security-team
accounts/production/* @infrastructure-team @security-team @compliance-team

This step will catch many bugs and help the complete engineering organization to be more efficient.

Phase 4: Automated Integration Back to ServiceNow

GitHub Actions provisions infrastructure and updates ServiceNow with the Configuration Item (CI):

# .github/workflows/provision-account.yml
name: Provision AWS Account
on:
  push:
    paths: ['accounts/**/*.yaml']
    
jobs:
  provision:
    runs-on: ubuntu-latest
    steps:
      - name: Terraform Apply
        run: terraform apply -auto-approve
      - name: Update ServiceNow CI
        run: |
          curl -X POST "$SERVICENOW_API/cmdb_ci_aws_account" \
            -H "Authorization: Bearer $SERVICENOW_TOKEN" \
            -d '{
              "account_id": "${{ vars.AWS_ACCOUNT_ID }}",
              "environment": "${{ vars.ENVIRONMENT }}",
              "cost_center": "${{ vars.COST_CENTER }}",
              "provisioned_date": "${{ vars.CURRENT_DATE }}"
            }'

ITSM compliance: ServiceNow maintains complete configuration item (CI) records and audit trails while technical teams work in their preferred tools.

Technical Implementation

Use a proper Infrastructure as Code (IaC) tool to provision the infrastructure, great examples are Terraform or Pulumi.

Repository Structure 

aws-account-factory/
├── docs/
│   ├── getting-started.md
│   └── templates/
├── accounts/
│   ├── engineering/
│   ├── security/
│   └── production/
├── terraform/
│   ├── modules/
│   └── environments/
├── scripts/
│   └── copy-template.sh/
└── .github/
    ├── workflows/
    └── CODEOWNERS

API Integration

GitHub Actions updates ServiceNow automatically:

- name: Update ServiceNow CMDB
  run: |
    curl -X POST "$SERVICENOW_API/cmdb_ci_aws_account" \
      -d '{
        "account_id": "${{ vars.AWS_ACCOUNT_ID }}",
        "environment": "${{ vars.ENVIRONMENT }}",
        "cost_center": "${{ vars.COST_CENTER }}"
      }'

Why This Works Better

Speed Improvements

  • PR feedback is immediate, not dependent on ITSM ticket updates
  • GitHub Actions runs in parallel, not sequential ITSM workflow steps
  • Developers can iterate on configurations without going back through forms

Better Collaboration

  • Infrastructure teams review actual YAML configurations
  • Security teams can suggest specific code changes
  • All discussions happen with full technical context

Discussion

ITSM tools and DevOps tools solve different problems. ServiceNow is good at managing access and compliance workflows. GitHub is industry leading at technical collaboration and automation.

This approach uses both tools for what they do well. The API integration keeps ServiceNow updated while letting technical teams work efficiently.

Have fun, now you only have about 25,000 lines of code to write!

Happy building!