Aligning a Distributed Team & Migrating Manual GCP to Terraform (IaC)
Executive Summary: A France-based company with developers across France and Istanbul was growing its engineering operations while working across several active projects. Over a ~3-month Fractional Tech Lead engagement, I supported the team in introducing a shared delivery cadence, modernized a legacy Rails application, established CI/CD, and helped a key data-analytics client transition its GCP infrastructure from console-based management to Terraform. The focus throughout was on creating practical systems that the existing teams could understand, adopt, and continue independently.
Context
The company had developers working across France and Istanbul, with the founder coordinating the work across both locations.
As the number of projects and developers grew, there was an opportunity to introduce more shared engineering practices:
- The team was coordinating much of its work through direct communication.
- Sprint planning and a regular engineering cadence had not yet been established.
- The existing backlog and task-management setup could be structured further to support planning.
- Active projects would benefit from consistent CI/CD workflows.
- A legacy Rails application needed a Ruby/Rails upgrade ahead of a Heroku runtime support deadline.
In parallel, a key French data-analytics client was operating a substantial GCP environment, with BigQuery as a major component alongside services such as Cloud Run.
The client’s existing GCP setup was managed through the GCP Console. Git repositories were already in place, but the infrastructure itself was not yet represented as Infrastructure as Code.
The engagement was scoped to approximately three months, so the objective was to make high-impact improvements while ensuring that ownership remained with the existing teams.
Decision
I approached the engagement across three connected areas: team practices, application delivery, and infrastructure enablement.
Team & Delivery Practices
I helped structure the existing backlog and introduced sprint planning and a lightweight recurring meeting cadence.
Initially, I joined the team’s Monday and Friday meetings, helped establish the format, and gradually stepped back as the team became comfortable running them independently.
I applied the same pattern to task and PR review, helping the founder and developers set up the workflow before stepping back. One useful shift was encouraging questions and requests to be recorded in the task-management system, so that context stayed available to the wider team rather than only in conversations.
I kept it well short of a full Scrum framework: enough structure to support the team’s existing way of working, and no process overhead it did not need.
Rails Modernization & CI/CD
The application ran on a Ruby version that Heroku was about to stop supporting. I first added tests around the critical paths and used RuboCop to bring the code to a consistent style. Rather than jumping straight to the latest Rails, I then upgraded one major version at a time: Rails 6, then 7, then 8, moving to a current Ruby along the way. Each step surfaced its own deprecations and breakages, and the tests showed exactly where. The result was deployed to Heroku staging for the team to verify.
I also introduced GitHub Actions-based CI/CD for active projects, with the develop branch deploying to staging so developers could verify changes before production.
Product-level development remained with the existing developers. My focus was on technical quality, modernization, and making delivery more repeatable.
GCP Infrastructure & Terraform
For the data-analytics client, the existing GCP infrastructure inventory was provided to us.
Together with the Istanbul developer I was training on Terraform, I translated that inventory into working Terraform configuration and progressively imported the existing resources using terraform import.
The implementation included:
- Modular Terraform configuration
- BigQuery resources
- Remote Terraform state in GCS
- A Makefile and documentation for state/bootstrap setup
terraform validateterraform planterraform test- Environment variables for secrets and credentials
The decision to use Terraform was driven by more than documentation.
The objective was to make infrastructure changes explicit, reviewable, reproducible, and transferable. A separate document would still require someone to translate instructions into manual GCP operations. Terraform allowed the infrastructure definition itself to become a version-controlled and testable artifact.
We also created a new empty GCP project to verify that the configuration could be used to reproduce the infrastructure.
I prepared an automated terraform apply workflow for staging and demonstrated how the team could enable and operate it when needed.
Consequences
- Team: The France and Istanbul developers gained a shared planning and communication rhythm while retaining their existing working style. Sprint planning continued after the engagement.
- Application delivery: The Rails application was upgraded ahead of its Heroku support deadline, critical areas gained test coverage, and active projects gained GitHub Actions-based CI/CD.
- Infrastructure: The client’s GCP configuration, including its heavily used BigQuery resources, became represented in modular, version-controlled Terraform code.
- Knowledge transfer: The Istanbul developer worked alongside me throughout the Terraform implementation and continued managing the infrastructure after the engagement.
- Client handover: The French client subsequently deployed their Development, Staging, and Production environments and adapted the Terraform implementation to their own requirements.
- Scope discipline: The engagement remained focused on technical enablement rather than taking over product development or permanently owning the team’s processes and infrastructure.
- Trade-off: The engagement was intentionally time-boxed, so I prioritized high-impact improvements over comprehensive organizational or architectural transformation.
- Trade-off: I chose gradual process adoption rather than introducing a full Scrum methodology at once, allowing the team to absorb and adapt the changes as part of their existing workflow.
The common principle across the engagement was:
Make important engineering knowledge explicit, reusable, testable, and transferable, while building on the team’s existing way of working.
When to revisit
As the GCP footprint grows across additional environments, regions, or services, the Terraform module, state, and environment boundaries should be reviewed and evolved accordingly.
This case note is an anonymized Architecture Decision Record (ADR) from a real-world engagement.