Two years ago, we had the gut feeling that we had implemented a pretty solid continuous integration practice in our development lab: all our builds were automated, we were running 70,000 unit and 130,000 integrations tests per week, and sprint reviews also comprised a regular check on test coverage for new features. However, over time some problems showed: builds were getting slower and slower, it was hard to fully test features locally before committing them, and as we had so many tests it took days to get feedback for a commit. As our codebase grew, these problems gradually worsened, and developer productivity started to suffer. In this talk we will tell our story how we moved from builds and tests running on a fixed schedule in our legacy build environment towards a pipeline as code approach in Jenkins. We will talk about how we convinced our managers, the daily benefits for our developers in terms of faster feedback loop, and how we did this while ensuring we could still release working products along the way.