Building, configuring, and maintaining Jenkins agents for all of the organization’s CI/CD pipelines becomes difficult and risky to maintain. In reality, this centrally managed approach doesn’t scale well as the demands for CI/CD grow in the organization. Essentially, this centralized team attempts to solve and support all permutations each individual delivery team will need from a pipeline (e.g., build/deploy resources and plugins). This first approach involves deploying a single Jenkins master with multiple Jenkins agents that teams use to run their build workloads (typically on physical hardware or virtual machines) completely managed by a centralized team. In many organizations, Jenkins is implemented in one of two approaches: (1) centralized management (top-down effort) and (2) individual team management (grassroots effort). In this post, I’ll review the Jenkins problem in more detail and then propose a container-based CI/CD solution for using ephemeral Jenkins masters with Kubernetes. It’s a serious and all too common challenge for enterprise organizations. As more teams onboard onto the pipeline, this scalability issue creates delivery bottlenecks. The DevOps team is left guessing as to the number of build agents needed. Here’s the problem: Many organizations have a single Jenkins master and a limited number of build agents with no ability to auto-scale Jenkins to meet delivery team demands. I mean, what could better represent ephemeral Jenkins build agents than the massive unending population of stormtroopers who lead ephemeral, short-lived lives (especially when the Jedi are around)? In conjunction of the recent release of, The Rise of Skywalker, the final movie in the Skywalker saga, I figured an image of stormtroopers was in order.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |