Rules

Inspiration

The rules themselves draw inspiration from the sometimes absurd realities of enterprise software development. The project has a humorous side, but its architecture, infrastructure, security, and automation are real. It was also an opportunity to learn OCaml by building something more substantial than programming exercises. When the GitLab Transcend Life After Code hackathon appeared, I saw an opportunity to take that learning project further: turn a small rules engine into a real cloud-native service and explore everything required to operate software after writing the code.

What it does

Rules is a JSON-based rules engine written in OCaml. It exposes REST endpoints that accept input data, retrieve applicable rules from PostgreSQL, evaluate them, and return the results. The service runs on Google Cloud Run, with authenticated access and database credentials managed securely. Beyond evaluating rules, the project demonstrates a complete DevSecOps lifecycle using GitLab: automated testing, container builds, CI/CD, deployment, security practices, and production observability. OpenTelemetry instrumentation exports traces, structured logs, and metrics to GitLab Observability, making the service's internal behavior visible.

How we built it

The application was developed in OCaml 5.5 using Dream for REST endpoints, Lwt for asynchronous operations, Yojson for JSON processing, Caqti for PostgreSQL access, and Alcotest for automated testing. PostgreSQL is hosted on Neon, and the application is containerized with Docker and deployed to Google Cloud Run. GitLab CI/CD automates compilation, testing, container validation, image publishing, and deployment. Cloud Run authentication, dedicated service accounts, restricted database permissions, and Google Secret Manager provide security controls. Development was AI-assisted, with several models contributing to implementation, testing, and infrastructure work. I coordinated the development, reviewed changes, made architectural decisions, investigated problems, and implemented the OpenTelemetry instrumentation myself. GitLab Duo Agent Platform capabilities were used to investigate CI/CD failures and production issues, including the Fix CI/CD Pipeline flow.

Challenges we ran into

Our biggest challenges appeared after the application itself was already working. The CI/CD pipeline repeatedly failed when Docker builds could not retrieve packages from Debian repositories. GitLab Duo investigated the failures, examined pipeline history and merge request changes, and established that the evidence did not support blaming the latest application changes. Further investigation identified a Docker-in-Docker networking problem. Adjusting the Docker build's networking configuration resolved the failures. Another challenge appeared when OpenTelemetry worked perfectly on my Ubuntu laptop but failed in Cloud Run with: Failure("resolution failed: unknown scheme") We investigated OCaml networking dependencies, native linking, and TLS before an AI-assisted investigation identified the real cause: the minimal Debian runtime image was missing the netbase package and its /etc/services definitions. Adding that package finally enabled telemetry exports from Cloud Run to GitLab. These experiences turned unexpected failures into opportunities to explore how AI-assisted investigation can support real DevSecOps work.

Accomplishments that we're proud of

The biggest accomplishment is transforming a small OCaml learning project into a working, secure, deployed, and observable cloud service. Some particularly satisfying milestones include:

• Building a functional OCaml rules engine with REST endpoints and PostgreSQL integration.
• Creating a suite of more than 500 automated tests.
• Automating the build, test, containerization, and deployment lifecycle through GitLab.
• Deploying to Google Cloud Run with authenticated access and restricted permissions.
• Completing security reviews and integrating Secret Manager.
• Implementing OpenTelemetry traces, logs, and metrics and seeing them displayed in GitLab Observability.
• Using GitLab Duo to investigate genuine pipeline failures, distinguish infrastructure problems from code regressions, and guide corrective changes.

What we learned

I learned how much engineering takes place after the code is written. A successful local build is only the beginning: an application must be tested, packaged, secured, deployed, monitored, and maintained. Working with multiple AI models reinforced the importance of human engineering judgment. AI tools can accelerate implementation and investigation, but their suggestions still need to be evaluated against real evidence. GitLab Duo's investigation of the CI/CD failures was especially instructive because its diagnosis evolved as new evidence became available. Finally, observability demonstrated its practical value immediately. The first production traces revealed that nearly all request latency came from loading rules from PostgreSQL, while evaluating those rules took only a fraction of a millisecond. The instrumentation did more than produce attractive dashboards: it identified the next engineering problem worth solving.

What's next for Rules

The next major improvement is Redis-based rules caching. Production traces showed approximately 1.4 seconds spent loading rules from PostgreSQL, compared with around 0.03 milliseconds evaluating them. While further measurements are needed, this suggests that reducing repeated database reads could significantly improve response times. A Redis cache would allow multiple Cloud Run instances to share cached rules while introducing useful new challenges involving expiration, invalidation, consistency, and failure handling.

Built With

• cloud-run
• gitlab
• gitlab-duo
• ocaml
• postgresql