Dec 2021 - Oct 2022 • Technical Deep Dive
Jenkins to GitLab Migration
Deep technical implementation details and lessons learned.
Technical Implementation
Technical details coming soon...
Frequently Asked Questions
Why GitLab over other CI/CD platforms?
" Great question. We evaluated several options, but GitLab won for three reasons: native Git integration that just made sense, the on-demand infrastructure model that would save us money, and the all-in-one platform approach that meant fewer tools to manage. The serverless execution model was the killer feature though. "How did you handle Jenkins-specific plugins in GitLab?" This was tricky. We had to find GitLab-native alternatives or build custom solutions. For example, our Jenkins security scanning plugin became a Docker image that we could run as a GitLab job. Some complex plugins required us to write custom scripts, but the end result was always simpler and more maintainable. "What about all the Jenkins job history and artifacts?" We kept Jenkins in read-only mode for six months after the migration. All historical build logs and artifacts remained accessible. For actively developed projects, we migrated the last 30 days of artifacts to GitLab. Anything older stayed in Jenkins archives - accessible but clearly marked as legacy. "How did you manage secrets and credentials?" This was actually easier in GitLab. We moved from Jenkins' credential store to GitLab's native CI/CD variables with environment scoping. The big win was that secrets were now versioned and scoped at the project level, making it much clearer who had access to what. "What was the biggest technical challenge?" Honestly? Dynamic pipeline generation. We had Jenkins jobs that would spawn other jobs based on complex logic. Recreating this in GitLab required us to master dynamic child pipelines and DAG (Directed Acyclic Graph) pipelines. It took weeks to get right, but the end result was more maintainable than the Jenkins version ever was. "How did you train hundreds of developers?" We used a train-the-trainer approach. Each team nominated a GitLab champion who we trained intensively. They then became the first point of contact for their team. We also created interactive tutorials, recorded workshops, and built a library of example pipelines for common scenarios. Why This Migration Still Influences My Work This project fundamentally changed how I think about infrastructure migrations. It's not about moving from A to B - it's about reimagining how things should work. The parallel validation approach I developed here became my template for every major migration since. Working with a platform serving over a million users taught me that reliability isn't negotiable. Every decision we made was filtered through the lens of "what happens if this fails at 3 AM?" That kind of thinking stays with you. But perhaps the biggest lesson was about patience and persistence. A year is a long time to work on a single migration. There were days when Jenkins failures made us want to rush, but we stuck to our methodical approach. That discipline paid off with a migration that succeeded without a single major incident. You know what's funny? Now when I see teams struggling with flaky CI/CD, I immediately think about this migration. The problems are usually the same - complexity that's accumulated over time, infrastructure that doesn't scale, and tools that fight against you instead of working with you. That's why this project matters. It proved that with the right approach, you can transform even the most critical, complex infrastructure without disrupting the business. You just need patience, a solid plan, and the determination to see it through. The migration succeeded, our developers got their lives back, and I learned lessons about large-scale infrastructure transformation that I still apply today. Sometimes the best projects are the ones that make problems disappear so completely that people forget they ever existed. That's the mark of good infrastructure work - when it becomes invisible, reliable, and just works. After a year of careful migration, that's exactly what we achieved.
How did you handle Jenkins-specific plugins in GitLab?
" This was tricky. We had to find GitLab-native alternatives or build custom solutions. For example, our Jenkins security scanning plugin became a Docker image that we could run as a GitLab job. Some complex plugins required us to write custom scripts, but the end result was always simpler and more maintainable. "What about all the Jenkins job history and artifacts?" We kept Jenkins in read-only mode for six months after the migration. All historical build logs and artifacts remained accessible. For actively developed projects, we migrated the last 30 days of artifacts to GitLab. Anything older stayed in Jenkins archives - accessible but clearly marked as legacy. "How did you manage secrets and credentials?" This was actually easier in GitLab. We moved from Jenkins' credential store to GitLab's native CI/CD variables with environment scoping. The big win was that secrets were now versioned and scoped at the project level, making it much clearer who had access to what. "What was the biggest technical challenge?" Honestly? Dynamic pipeline generation. We had Jenkins jobs that would spawn other jobs based on complex logic. Recreating this in GitLab required us to master dynamic child pipelines and DAG (Directed Acyclic Graph) pipelines. It took weeks to get right, but the end result was more maintainable than the Jenkins version ever was. "How did you train hundreds of developers?" We used a train-the-trainer approach. Each team nominated a GitLab champion who we trained intensively. They then became the first point of contact for their team. We also created interactive tutorials, recorded workshops, and built a library of example pipelines for common scenarios. Why This Migration Still Influences My Work This project fundamentally changed how I think about infrastructure migrations. It's not about moving from A to B - it's about reimagining how things should work. The parallel validation approach I developed here became my template for every major migration since. Working with a platform serving over a million users taught me that reliability isn't negotiable. Every decision we made was filtered through the lens of "what happens if this fails at 3 AM?" That kind of thinking stays with you. But perhaps the biggest lesson was about patience and persistence. A year is a long time to work on a single migration. There were days when Jenkins failures made us want to rush, but we stuck to our methodical approach. That discipline paid off with a migration that succeeded without a single major incident. You know what's funny? Now when I see teams struggling with flaky CI/CD, I immediately think about this migration. The problems are usually the same - complexity that's accumulated over time, infrastructure that doesn't scale, and tools that fight against you instead of working with you. That's why this project matters. It proved that with the right approach, you can transform even the most critical, complex infrastructure without disrupting the business. You just need patience, a solid plan, and the determination to see it through. The migration succeeded, our developers got their lives back, and I learned lessons about large-scale infrastructure transformation that I still apply today. Sometimes the best projects are the ones that make problems disappear so completely that people forget they ever existed. That's the mark of good infrastructure work - when it becomes invisible, reliable, and just works. After a year of careful migration, that's exactly what we achieved.
What about all the Jenkins job history and artifacts?
" We kept Jenkins in read-only mode for six months after the migration. All historical build logs and artifacts remained accessible. For actively developed projects, we migrated the last 30 days of artifacts to GitLab. Anything older stayed in Jenkins archives - accessible but clearly marked as legacy. "How did you manage secrets and credentials?" This was actually easier in GitLab. We moved from Jenkins' credential store to GitLab's native CI/CD variables with environment scoping. The big win was that secrets were now versioned and scoped at the project level, making it much clearer who had access to what. "What was the biggest technical challenge?" Honestly? Dynamic pipeline generation. We had Jenkins jobs that would spawn other jobs based on complex logic. Recreating this in GitLab required us to master dynamic child pipelines and DAG (Directed Acyclic Graph) pipelines. It took weeks to get right, but the end result was more maintainable than the Jenkins version ever was. "How did you train hundreds of developers?" We used a train-the-trainer approach. Each team nominated a GitLab champion who we trained intensively. They then became the first point of contact for their team. We also created interactive tutorials, recorded workshops, and built a library of example pipelines for common scenarios. Why This Migration Still Influences My Work This project fundamentally changed how I think about infrastructure migrations. It's not about moving from A to B - it's about reimagining how things should work. The parallel validation approach I developed here became my template for every major migration since. Working with a platform serving over a million users taught me that reliability isn't negotiable. Every decision we made was filtered through the lens of "what happens if this fails at 3 AM?" That kind of thinking stays with you. But perhaps the biggest lesson was about patience and persistence. A year is a long time to work on a single migration. There were days when Jenkins failures made us want to rush, but we stuck to our methodical approach. That discipline paid off with a migration that succeeded without a single major incident. You know what's funny? Now when I see teams struggling with flaky CI/CD, I immediately think about this migration. The problems are usually the same - complexity that's accumulated over time, infrastructure that doesn't scale, and tools that fight against you instead of working with you. That's why this project matters. It proved that with the right approach, you can transform even the most critical, complex infrastructure without disrupting the business. You just need patience, a solid plan, and the determination to see it through. The migration succeeded, our developers got their lives back, and I learned lessons about large-scale infrastructure transformation that I still apply today. Sometimes the best projects are the ones that make problems disappear so completely that people forget they ever existed. That's the mark of good infrastructure work - when it becomes invisible, reliable, and just works. After a year of careful migration, that's exactly what we achieved.
How did you manage secrets and credentials?
" This was actually easier in GitLab. We moved from Jenkins' credential store to GitLab's native CI/CD variables with environment scoping. The big win was that secrets were now versioned and scoped at the project level, making it much clearer who had access to what. "What was the biggest technical challenge?" Honestly? Dynamic pipeline generation. We had Jenkins jobs that would spawn other jobs based on complex logic. Recreating this in GitLab required us to master dynamic child pipelines and DAG (Directed Acyclic Graph) pipelines. It took weeks to get right, but the end result was more maintainable than the Jenkins version ever was. "How did you train hundreds of developers?" We used a train-the-trainer approach. Each team nominated a GitLab champion who we trained intensively. They then became the first point of contact for their team. We also created interactive tutorials, recorded workshops, and built a library of example pipelines for common scenarios. Why This Migration Still Influences My Work This project fundamentally changed how I think about infrastructure migrations. It's not about moving from A to B - it's about reimagining how things should work. The parallel validation approach I developed here became my template for every major migration since. Working with a platform serving over a million users taught me that reliability isn't negotiable. Every decision we made was filtered through the lens of "what happens if this fails at 3 AM?" That kind of thinking stays with you. But perhaps the biggest lesson was about patience and persistence. A year is a long time to work on a single migration. There were days when Jenkins failures made us want to rush, but we stuck to our methodical approach. That discipline paid off with a migration that succeeded without a single major incident. You know what's funny? Now when I see teams struggling with flaky CI/CD, I immediately think about this migration. The problems are usually the same - complexity that's accumulated over time, infrastructure that doesn't scale, and tools that fight against you instead of working with you. That's why this project matters. It proved that with the right approach, you can transform even the most critical, complex infrastructure without disrupting the business. You just need patience, a solid plan, and the determination to see it through. The migration succeeded, our developers got their lives back, and I learned lessons about large-scale infrastructure transformation that I still apply today. Sometimes the best projects are the ones that make problems disappear so completely that people forget they ever existed. That's the mark of good infrastructure work - when it becomes invisible, reliable, and just works. After a year of careful migration, that's exactly what we achieved.
What was the biggest technical challenge?
" Honestly? Dynamic pipeline generation. We had Jenkins jobs that would spawn other jobs based on complex logic. Recreating this in GitLab required us to master dynamic child pipelines and DAG (Directed Acyclic Graph) pipelines. It took weeks to get right, but the end result was more maintainable than the Jenkins version ever was. "How did you train hundreds of developers?" We used a train-the-trainer approach. Each team nominated a GitLab champion who we trained intensively. They then became the first point of contact for their team. We also created interactive tutorials, recorded workshops, and built a library of example pipelines for common scenarios. Why This Migration Still Influences My Work This project fundamentally changed how I think about infrastructure migrations. It's not about moving from A to B - it's about reimagining how things should work. The parallel validation approach I developed here became my template for every major migration since. Working with a platform serving over a million users taught me that reliability isn't negotiable. Every decision we made was filtered through the lens of "what happens if this fails at 3 AM?" That kind of thinking stays with you. But perhaps the biggest lesson was about patience and persistence. A year is a long time to work on a single migration. There were days when Jenkins failures made us want to rush, but we stuck to our methodical approach. That discipline paid off with a migration that succeeded without a single major incident. You know what's funny? Now when I see teams struggling with flaky CI/CD, I immediately think about this migration. The problems are usually the same - complexity that's accumulated over time, infrastructure that doesn't scale, and tools that fight against you instead of working with you. That's why this project matters. It proved that with the right approach, you can transform even the most critical, complex infrastructure without disrupting the business. You just need patience, a solid plan, and the determination to see it through. The migration succeeded, our developers got their lives back, and I learned lessons about large-scale infrastructure transformation that I still apply today. Sometimes the best projects are the ones that make problems disappear so completely that people forget they ever existed. That's the mark of good infrastructure work - when it becomes invisible, reliable, and just works. After a year of careful migration, that's exactly what we achieved.
How did you train hundreds of developers?
" We used a train-the-trainer approach. Each team nominated a GitLab champion who we trained intensively. They then became the first point of contact for their team. We also created interactive tutorials, recorded workshops, and built a library of example pipelines for common scenarios. Why This Migration Still Influences My Work This project fundamentally changed how I think about infrastructure migrations. It's not about moving from A to B - it's about reimagining how things should work. The parallel validation approach I developed here became my template for every major migration since. Working with a platform serving over a million users taught me that reliability isn't negotiable. Every decision we made was filtered through the lens of "what happens if this fails at 3 AM?" That kind of thinking stays with you. But perhaps the biggest lesson was about patience and persistence. A year is a long time to work on a single migration. There were days when Jenkins failures made us want to rush, but we stuck to our methodical approach. That discipline paid off with a migration that succeeded without a single major incident. You know what's funny? Now when I see teams struggling with flaky CI/CD, I immediately think about this migration. The problems are usually the same - complexity that's accumulated over time, infrastructure that doesn't scale, and tools that fight against you instead of working with you. That's why this project matters. It proved that with the right approach, you can transform even the most critical, complex infrastructure without disrupting the business. You just need patience, a solid plan, and the determination to see it through. The migration succeeded, our developers got their lives back, and I learned lessons about large-scale infrastructure transformation that I still apply today. Sometimes the best projects are the ones that make problems disappear so completely that people forget they ever existed. That's the mark of good infrastructure work - when it becomes invisible, reliable, and just works. After a year of careful migration, that's exactly what we achieved.
what happens if this fails at 3 AM?
" That kind of thinking stays with you. But perhaps the biggest lesson was about patience and persistence. A year is a long time to work on a single migration. There were days when Jenkins failures made us want to rush, but we stuck to our methodical approach. That discipline paid off with a migration that succeeded without a single major incident. You know what's funny? Now when I see teams struggling with flaky CI/CD, I immediately think about this migration. The problems are usually the same - complexity that's accumulated over time, infrastructure that doesn't scale, and tools that fight against you instead of working with you. That's why this project matters. It proved that with the right approach, you can transform even the most critical, complex infrastructure without disrupting the business. You just need patience, a solid plan, and the determination to see it through. The migration succeeded, our developers got their lives back, and I learned lessons about large-scale infrastructure transformation that I still apply today. Sometimes the best projects are the ones that make problems disappear so completely that people forget they ever existed. That's the mark of good infrastructure work - when it becomes invisible, reliable, and just works. After a year of careful migration, that's exactly what we achieved.