Swipe-to-Ship

• 

  Pipline

• 

  Branch merge

Inspiration

Shipping a software change involves much more than writing code. A developer must move from an issue to a plan, implement the change, write tests, review the code, pass CI/CD checks, deploy safely, and verify the result.

AI can accelerate individual steps, but speed alone is not enough. Teams also need reliable testing, deployment safeguards, human oversight, and an auditable record of what happened.

Swipe to Ship explores how GitLab AI-assisted development and a guarded release workflow can help teams move from an issue to a verified deployment with greater confidence.

What It Does

Swipe to Ship connects issue-driven development with AI-assisted engineering workflows and controlled deployment.

• AI-assisted development: Uses GitLab Duo workflows to support planning, implementation, and test-generation tasks.
• Automated validation: Runs CI/CD pipelines, tests, and lint checks before changes progress.
• A working REST API: Demonstrates item listing, pagination, case-insensitive item search, and a health endpoint.
• Safer releases: Deploys to Google Cloud Run with staging and production environments, canary verification, and production promotion.
• Configuration drift detection: Checks deployed service configuration against the expected settings.
• Auditable workflow: Collects issue, merge request, pipeline, and deployment events in a hash-linked evidence ledger.

The goal is not to remove human judgment. It is to make the path from code change to release more structured, testable, and observable.

How We Built It

The project combines GitLab, GitLab Duo, GitLab CI/CD, a Python REST API, and Google Cloud Run.

GitLab issues provide concrete development tasks. AI-assisted workflows help with planning and engineering changes, while merge requests and CI/CD pipelines provide the validation and review path. The deployment workflow supports staging, canary checks, and production promotion.

The API exposes endpoints for item listing and search, pagination, and health verification. Automated checks validate API behavior and reject invalid pagination inputs. Deployment checks verify that the service is healthy and that its configuration matches expectations.

We also created an evidence bundle containing workflow events and a hash-linked audit ledger, making it easier to inspect the relationship between development activity and deployment outcomes.

Challenges We Faced

Several issues emerged only when the complete workflow was exercised.

• Health-check consistency: The application's health endpoint and deployment checks initially disagreed. We aligned the health path across the application, tests, and deployment verification.
• First-deployment behavior: Cloud Run did not support the same no-traffic deployment option when creating a new service as it did for subsequent deployments. We updated the pipeline to handle first deployment and later canary releases separately.
• Configuration drift: The drift checker initially inspected revision-level scaling configuration instead of the service-level setting. We corrected the check and verified that the expected configuration matched the deployed service.
• AI workflow reliability: Not every agent action succeeded automatically. Some review and merge actions required manual intervention, reinforcing the importance of clear human approval boundaries.

We addressed these problems through focused changes, merge requests, CI/CD validation, and production verification.

What We Learned

We learned that a useful AI-assisted engineering system needs more than code generation. It needs reliable interfaces, explicit deployment contracts, automated tests, observable state, and a clear separation between actions that can be automated and actions that require human judgment.

We also learned the value of testing infrastructure behavior—not just application code. Health checks, first-deployment conditions, service-level configuration, and production verification can all become failure points if they are not tested directly.

Results

The final production verification confirmed that the deployed service was healthy and that the item-listing, search, and pagination endpoints behaved as expected.

In the recorded production monitoring run, 20 checks completed with a reported error rate of 0.0 and p95 latency of 1,338 ms. The final production revision was serving 100% of production traffic.

These results demonstrate the current implementation; they are not a guarantee of future production performance.

What's Next

The next steps are to strengthen least-privilege access, expand real-account acceptance testing, improve risk-based human approval for sensitive changes, and add more comprehensive automated recovery and rollback checks.

The long-term vision is simple: turn a development issue into a tested, reviewed, verified release—with evidence at every important step.

Built With

• ai-assisted-development
• audit-logging
• automated-testing
• canary-deployments
• ci/cd
• configuration
• detection
• devops
• drift
• fastapi
• gitlab
• gitlab-ci/cd
• gitlab-duo
• google-cloud
• google-cloud-build
• google-cloud-run
• google-secret-manager
• openapi
• pytest
• python
• rest-api
• ruff