9. Development Workflow: New Product

← Back to Table of Contents | Previous: GitLab CI/CD | Next: Existing Code Integration →

9.1 When to Use This Workflow

Use this workflow when starting a microservices project from scratch. There is no existing codebase — you are building the product, the infrastructure, and the Kiro configuration from the ground up.

9.2 Phase 1: Foundation (Week 1)

Step 1: Create Repositories

1. Create app-repo (application mono-repo)
2. Create infra-repo (Terraform infrastructure)
3. Initialize both with the file hierarchy from Section 11

Step 2: Define Module Boundaries

Before writing any code, define the microservice modules:

src/
├── auth/          → Authentication & authorization
├── billing/       → Payments, invoices, subscriptions
├── orders/        → Order lifecycle management
├── catalog/       → Product catalog
├── gateway/       → API gateway / BFF
└── shared/        → Shared types and interfaces

Adjust modules to your domain. The key rule: each module is a bounded context with clear ownership.

Step 3: Set Up Kiro Configuration

1. Copy the .kiro/ directory from Section 11
2. Customize steering rules for your modules
3. Install hooks (test-on-save, lint-on-save, verify-tests, module-boundary)

Step 4: Set Up Infrastructure Base

In the infra repo: 1. Create the VPC module 2. Create the ECS cluster module 3. Create the ECR repositories (one per microservice) 4. Set up remote state (S3 + DynamoDB) 5. Deploy the dev environment

Step 5: Set Up CI/CD

1. Copy GitLab CI templates from Section 8
2. Configure GitLab CI/CD variables (AWS credentials, ECR registry URL)
3. Verify the pipeline runs on a test PR

9.3 Phase 2: Skeleton Services (Week 1–2)

Step 6: Generate Service Skeletons with Kiro

For each module, use Kiro specs to generate the initial structure:

For each module:
1. Create a Kiro spec: .kiro/specs/<module>-skeleton/
2. Define requirements: basic CRUD, health check endpoint
3. Let Kiro generate: controller, service, repository, models
4. Kiro also generates: unit tests for each component
5. Verify tests pass
6. Commit and merge to main

Step 7: Define API Contracts

Before modules start interacting, define contracts in shared/:

src/shared/
├── interfaces/
│   ├── auth.interface.ts      → What auth exposes
│   ├── billing.interface.ts   → What billing exposes
│   └── orders.interface.ts    → What orders exposes
└── types/
    ├── user.types.ts
    ├── order.types.ts
    └── payment.types.ts

These are human-maintained. Kiro agents consume them but do not modify them without approval.

Step 8: Dockerize Each Service

Create a Dockerfile per service:

# docker/auth/Dockerfile
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY src/auth/ src/auth/
COPY src/shared/ src/shared/
COPY tsconfig.json .
RUN npm run build -- --filter=auth

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/auth/main.js"]

9.4 Phase 3: Feature Development (Sprint Cycles)

Once the foundation is in place, development follows the standard sprint cycle:

Sprint Planning

1. Product backlog items are decomposed into module-scoped tasks
2. Each task specifies: module, acceptance criteria, API changes (if any)
3. Tasks are assigned to developer + Kiro pairs

During Sprint

1. Developer creates a Kiro spec for the feature
2. Kiro generates code + tests within the module
3. Developer reviews, adjusts, commits
4. PR opened → reviewed → CI validates → merge to main
5. Repeat every few hours

Sprint Review

• Demo from main (always deployable)
• Deploy to staging for stakeholder review

9.5 Recommendations for New Products

← Back to Table of Contents | Previous: GitLab CI/CD | Next: Existing Code Integration →