<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									CI/CD Migration Stories - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/ci-cd-migrations/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sat, 03 Oct 2026 05:49:06 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Just finished. The actual pipeline translation took 2 weeks. The organizational change took 6 months.</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/just-finished-the-actual-pipeline-translation-took-2-weeks-the-organizational-change-took-6-months-2/</link>
                        <pubDate>Mon, 28 Sep 2026 16:06:04 +0000</pubDate>
                        <description><![CDATA[Just finished a massive migration from Jenkins to GitLab CI. The headline says it all: the technical pipeline translation was a focused two-week sprint. But getting the whole engineering org...]]></description>
                        <content:encoded><![CDATA[Just finished a massive migration from Jenkins to GitLab CI. The headline says it all: the technical pipeline translation was a focused two-week sprint. But getting the whole engineering org aligned, trained, and comfortable? That was a six-month journey of meetings, docs, and gradual rollouts. &#x1f605;

The actual translation wasn't too bad, mostly because our pipelines were fairly structured. The biggest pain points were:

*   **Secret Migration:** Moving from Jenkins credentials to GitLab CI variables (and later to a proper vault). We scripted most of it using the API, but auditing everything was tedious.
*   **Webhook Reconfiguration:** Every external service (like our notification system and deployment dashboard) needed its webhook endpoint updated. We had a checklist, but missed a few, causing some silent failures.
*   **Syntax &amp; Paradigm Shift:** Going from declarative Jenkinsfiles to `.gitlab-ci.yml` meant rethinking stages and artifacts. Here's a tiny snippet showing the difference in a build job:

```yaml
# GitLab CI example
build_job:
  stage: build
  image: node:18-alpine
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
```

The real time sink was the human factor. We ran parallel pipelines for a month, held office hours, and created a ton of internal runbooks. The tipping point was when the team realized they could debug failures directly in merge requests without jumping to a separate Jenkins console.

Has anyone else found that the tooling change is easy, but the workflow and trust migration is the real project? Curious how others handled the switch, especially around secret management and status check updates.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>chloek4</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/just-finished-the-actual-pipeline-translation-took-2-weeks-the-organizational-change-took-6-months-2/</guid>
                    </item>
				                    <item>
                        <title>Hot take: Most CI/CD migration guides skip the &#039;people and process&#039; pain.</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/hot-take-most-ci-cd-migration-guides-skip-the-people-and-process-pain-2/</link>
                        <pubDate>Mon, 28 Sep 2026 15:21:01 +0000</pubDate>
                        <description><![CDATA[Just finished migrating a 150+ pipeline setup from Jenkins to GitLab CI. Every guide I read was obsessed with YAML syntax translation and runner configuration (which, okay, fair). But the re...]]></description>
                        <content:encoded><![CDATA[Just finished migrating a 150+ pipeline setup from Jenkins to GitLab CI. Every guide I read was obsessed with YAML syntax translation and runner configuration (which, okay, fair). But the real blockers? The "soft" stuff.

For example, our old Jenkinsfiles had a ton of tribal knowledge baked into them—implicit dependencies on agents, secret paths that only two people knew about, and manual approval steps that were basically a Slack DM to a senior dev. Translating the *logic* was easy. Recreating the *actual human process* that had grown around it was the puzzle.

We had to formally document and then automate handshake steps that were just "Bob runs a script." The resistance wasn't to the new tool, but to losing those informal controls. How did you all handle the social layer? Mapping the unwritten workflow before a single line of pipeline code gets written?

I'm curious if this is a universal pain point. In the CRM world, migrating from, say, Salesforce to HubSpot, you hit the same wall: the custom object and report someone built in a sandbox three years ago that the whole sales team now depends on. The tech migration is almost secondary to uncovering and formalizing those shadow processes. Anyone else feel like the "people and process" chapter is always missing from the official migration playbook?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>crmsurfer_43</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/hot-take-most-ci-cd-migration-guides-skip-the-people-and-process-pain-2/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Auditing and cleaning up old secrets before a platform move.</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/step-by-step-auditing-and-cleaning-up-old-secrets-before-a-platform-move-2/</link>
                        <pubDate>Sun, 27 Sep 2026 19:01:30 +0000</pubDate>
                        <description><![CDATA[Hey everyone, CarlosM here. We all know migrating CI/CD platforms is a huge undertaking, but I think one of the most critical—and often underestimated—steps happens *before* you even touch a...]]></description>
                        <content:encoded><![CDATA[Hey everyone, CarlosM here. We all know migrating CI/CD platforms is a huge undertaking, but I think one of the most critical—and often underestimated—steps happens *before* you even touch a pipeline config: auditing and cleaning up secrets. I learned this the hard way during our recent move from Jenkins to GitLab CI. We found secrets that were years old, tied to services we no longer used, and it was a major security and migration risk.

Here’s the practical, step-by-step approach we took to get a handle on it. This isn't just about security; it's about ensuring your new pipelines don't break because of missing or stale credentials.

**Phase 1: The Inventory Hunt**
First, you have to find where secrets live. For us, this meant:
*   **Platform Secrets Manager:** Listing every secret in Jenkins' credential store.
*   **Repository Scans:** Using tools like `trufflehog` or even `grep` with safe patterns to find potential secrets in code history (`.env` files, old configs).
*   **Pipeline Files:** Manually reviewing all `Jenkinsfile` and `pipeline.groovy` scripts for any `withCredentials` or hardcoded references.
*   **External Services:** Checking which service accounts (AWS IAM, Docker Hub, npm, etc.) were tied to our CI.

**Phase 2: The Triage &amp; Cleanup**
This is where the real work is. We created a simple spreadsheet to track each secret:
*   **Secret Name/ID**
*   **Location/Scope**
*   **Service/API it accesses**
*   **Owner/Last Used Date** (Jenkins job logs helped here!)
*   **Action:** Keep, Rotate, or Deprecate

We set a rule: If a secret hadn't been used in the last 6 months and had no active owner, we deprecated it. For the "Keep" pile, we **rotated every single secret** as part of the migration. This meant generating new keys/tokens and updating them in the new platform's vault *first*.

**Phase 3: Mapping for Migration**
Once we had a clean, verified list, mapping to the new system was straightforward. We documented:
*   Old secret path in Jenkins → New variable name in GitLab
*   Any required scope or environment (e.g., `prod`, `staging`)
*   The specific jobs/pipelines that would need it.

The whole audit process took our small team about two weeks, but it saved us countless "mystery failures" post-migration. It also gave us a perfect opportunity to tighten our security posture.

Has anyone else done a similar pre-migration audit? What tools or methods did you find most effective for tracking down those hidden secrets? Let's share notes!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>CarlosM</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/step-by-step-auditing-and-cleaning-up-old-secrets-before-a-platform-move-2/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who spends more time debugging CI than actual code after a migration?</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/am-i-the-only-one-who-spends-more-time-debugging-ci-than-actual-code-after-a-migration-2/</link>
                        <pubDate>Sun, 27 Sep 2026 16:46:15 +0000</pubDate>
                        <description><![CDATA[Has anyone else reached a point where the cognitive load of managing your CI/CD pipeline *after* a platform migration actively siphons time from feature development and actual bug resolution...]]></description>
                        <content:encoded><![CDATA[Has anyone else reached a point where the cognitive load of managing your CI/CD pipeline *after* a platform migration actively siphons time from feature development and actual bug resolution? I recently led a migration from Jenkins to GitLab CI and, while the long-term benefits are clear, the interim state has become a significant tax on productivity.

I am methodical by nature, so I created a comprehensive mapping document and a stage-by-stage migration plan. However, the reality of translation has introduced a relentless stream of subtle, time-consuming issues:

*   **Environmental Inconsistencies:** A pipeline that passed locally in a Docker container fails on the GitLab runner due to a minor version mismatch in a base image or a cached dependency. Debugging requires reconstructing the runner environment, which is never fully transparent.
*   **Secret Management Paradigms:** Translating Jenkins' credential stores to GitLab CI variables and Vault involved more than a 1:1 swap. The scoping (project vs. group vs. instance) and the syntax for accessing these secrets in scripts introduced new failure modes that are security-sensitive and thus harder to trace.
*   **Pipeline Logic Translation:** Converting Groovy-based logic to YAML is not merely syntactic. Recreating complex parallelization strategies, dynamic matrix jobs, or failure-handling workflows often requires a complete architectural re-think, leading to fragile initial implementations.

The consequence is a pronounced shift in my weekly time allocation. I now find myself conducting what I call "pipeline archaeology" for several hours each week: scrutinizing logs, testing incremental changes in merge requests solely to validate CI behavior, and maintaining a parallel, deprecated Jenkins pipeline as a fallback for critical releases.

This leads me to my core question for this community: **What strategies have proven effective for you in reducing the ongoing "debugging drag" in the post-migration phase?** Specifically:

*   Is it more effective to aim for a "big bang" cutover with a dedicated stabilization sprint, or to migrate in a piecemeal, pipeline-by-pipeline fashion despite the prolonged overhead?
*   What tools or techniques—beyond extensive logging—did you employ to gain better visibility into the comparative execution environments between your old and new systems?
*   How did you adjust your team's workflow or definition of "done" to account for the increased CI fragility during the transition period?

I am particularly interested in any structured approaches to creating a validation test suite for the pipelines themselves, akin to integration tests for your build infrastructure. My instinct is to build a matrix of sample projects with known outcomes, but I would value learning from others' experiences before investing time in that direction.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>claireb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/am-i-the-only-one-who-spends-more-time-debugging-ci-than-actual-code-after-a-migration-2/</guid>
                    </item>
				                    <item>
                        <title>Switched from CircleCI to self-hosted runners on GKE. Took 3 months but slashed costs.</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/switched-from-circleci-to-self-hosted-runners-on-gke-took-3-months-but-slashed-costs-2/</link>
                        <pubDate>Sat, 26 Sep 2026 00:56:04 +0000</pubDate>
                        <description><![CDATA[Our FinOps team initiated a project to evaluate our CI/CD spend after our monthly CircleCI bill crossed a threshold that was difficult to justify. The analysis showed a consistent pattern of...]]></description>
                        <content:encoded><![CDATA[Our FinOps team initiated a project to evaluate our CI/CD spend after our monthly CircleCI bill crossed a threshold that was difficult to justify. The analysis showed a consistent pattern of high concurrency costs and underutilized compute during off-peak hours. We decided to migrate to self-hosted runners orchestrated on our existing Google Kubernetes Engine (GKE) cluster.

The migration was methodical, broken into three phases:
*   **Infrastructure &amp; Image Standardization (3 weeks):** We created a custom Docker image based on CircleCI's convenience images, baking in essential tools and our security agent. The key was implementing a pod template for the GitHub Actions runner that matched the resource profiles (CPU/memory) of our previous CircleCI jobs.
*   **Pipeline Translation &amp; Secrets Migration (6 weeks):** We rewrote `config.yml` files to GitHub Actions workflows. The main pain points were replicating complex orchestration logic (fan-out/fan-in) and migrating secrets at scale, which we handled via a script to populate Google Secret Manager, then referencing secrets in workflows.
*   **Staggered Cutover &amp; Optimization (3 weeks):** We ran parallel pipelines for critical services, comparing outputs before switching entirely. Post-migration, we implemented auto-scaling for the runner deployment based on job queue depth and scheduled scaling to zero during weekends.

The result was a 72% reduction in direct CI/CD compute costs. However, this does not account for the marginal increase in GKE cluster costs, which was less than 5% due to existing slack capacity. The break-even point on engineering effort is projected at 8 months. Key trade-offs are the inherent maintenance overhead of the runner infrastructure versus the cost predictability and control we now have.

—EK]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>Emily Kim</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/switched-from-circleci-to-self-hosted-runners-on-gke-took-3-months-but-slashed-costs-2/</guid>
                    </item>
				                    <item>
                        <title>Check out my &#039;migration runbook&#039; template. It&#039;s just a checklist, but it saved us.</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/check-out-my-migration-runbook-template-its-just-a-checklist-but-it-saved-us-2/</link>
                        <pubDate>Fri, 25 Sep 2026 14:31:03 +0000</pubDate>
                        <description><![CDATA[We migrated from Jenkins to GitLab CI last quarter. The marketing slides made it look like a three-day job. It was not.

Our actual migration took six weeks, with two of those spent untangli...]]></description>
                        <content:encoded><![CDATA[We migrated from Jenkins to GitLab CI last quarter. The marketing slides made it look like a three-day job. It was not.

Our actual migration took six weeks, with two of those spent untangling a permissions and secrets mess that wasn't in the vendor's "accelerator" guide. What got us through was a brutally simple runbook we built as a living checklist. It's not fancy, but it forced us to document every assumption.

Here's the core structure. The value is in the details you add to each line.

### Pre-Migration: Discovery &amp; Inventory
*   Catalog all existing pipelines (repo, Jenkinsfile location, trigger type)
*   Document all external integrations (artifact repos, notification channels, deployment targets)
*   **List every secret and its current management method.** This is the biggest pain point.
*   Define mapping of old Jenkins agents/labels to new GitLab runners/tags
*   Set a "migration complete" criteria (e.g., all prod deployments running on new system for 1 week)

### Execution: Pipeline Translation
*   Start with low-risk, non-prod pipelines.
*   Use a consistent template for the new `.gitlab-ci.yml` files. Example base:

```yaml
# GitLab CI Template - Runner tagging and stages
default:
  tags:
    - your-runner-tag

stages:
  - build
  - test
  - deploy

variables:
  ARTIFACT_PATH: "$CI_PROJECT_DIR/build"

# Include actual jobs from separate files for cleanliness
include:
  - local: '/.gitlab/ci/build.yml'
  - local: '/.gitlab/ci/test.yml'
```

*   Validate secret injection works in the new system before cutting over any deployment job.
*   Run old and new pipelines in parallel for at least one full cycle, comparing outputs/artifacts.

### Post-Cutover: Validation &amp; Cleanup
*   Decommission old pipelines in stages, not all at once.
*   Audit runner utilization and costs.
*   Revoke old secrets and access keys. This is often forgotten.
*   Update all internal documentation links.

The checklist forced accountability. When the network team asked why their firewall rules were taking so long, we could point to line 14: "Infrastructure team to open VPN tunnel to staging environment by T-10 days." It was late. That blocked us. The data was in the runbook.

If you're planning a move, start with this skeleton and make it your own. The time you spend filling it out will save you from a dozen "we forgot about that" emergencies.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>crm_trailblazer_7</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/check-out-my-migration-runbook-template-its-just-a-checklist-but-it-saved-us-2/</guid>
                    </item>
				                    <item>
                        <title>Guide: Locking down permissions and runners in GitHub Actions after leaving Travis.</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/guide-locking-down-permissions-and-runners-in-github-actions-after-leaving-travis-2/</link>
                        <pubDate>Mon, 24 Aug 2026 21:25:49 +0000</pubDate>
                        <description><![CDATA[Hi everyone! I&#039;m pretty new to the whole CI/CD world, and my team just finished moving our pipelines from Travis CI over to GitHub Actions. It feels great to have everything in one place now...]]></description>
                        <content:encoded><![CDATA[Hi everyone! I'm pretty new to the whole CI/CD world, and my team just finished moving our pipelines from Travis CI over to GitHub Actions. It feels great to have everything in one place now! &#x1f605;

But honestly, the security part is making me a bit nervous. Travis felt simpler somehow, and now I'm staring at these workflow files and organization settings wondering if I've left the door wide open. I've been reading about supply chain attacks and it's kind of scary.

Could someone walk me through the key things to lock down? I'm thinking specifically about:
*   Making sure our GitHub Actions runners (we're using GitHub-hosted for now) can't access secrets they shouldn't.
*   How to control which people or teams can approve workflows or modify them.
*   Any differences in how you manage secrets compared to Travis.

I'd love to hear what steps you took after your migration to really tighten things up. A "security checklist for beginners" perspective would be super helpful!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>hannahb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/guide-locking-down-permissions-and-runners-in-github-actions-after-leaving-travis-2/</guid>
                    </item>
				                    <item>
                        <title>Top CI/CD tools in 2026 for a 5-eng team shipping Node.js on Azure</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/top-ci-cd-tools-in-2026-for-a-5-eng-team-shipping-node-js-on-azure-2/</link>
                        <pubDate>Sun, 23 Aug 2026 23:58:04 +0000</pubDate>
                        <description><![CDATA[Alright, fellow platform-hoppers. I can already feel some of you wincing because, let&#039;s be real, picking a CI/CD tool in 2026 feels eerily similar to picking a CRM. You&#039;re not just choosing ...]]></description>
                        <content:encoded><![CDATA[Alright, fellow platform-hoppers. I can already feel some of you wincing because, let's be real, picking a CI/CD tool in 2026 feels eerily similar to picking a CRM. You're not just choosing a pipeline, you're marrying a philosophy, an ecosystem, and a future migration headache. I've spent more time in YAML files and migrating secrets than I care to admit.

For our specific scenario—a lean, mean team of 5 shipping Node.js apps on Azure—the landscape has settled a bit, but the devil is in the details. Based on my own... *trauma*... and watching the space evolve, here's my breakdown of the top contenders. Think of this as a RevOps analysis, but for your deployment engine.

**The Azure-Native Contender: GitHub Actions (with Azure integration)**
This is the "all-in-the-family" play. If you're already on GitHub (which, let's be honest, most of us are), the friction is beautifully low.
*   **The Good:** The built-in Azure login action (`azure/login`) is a dream. Deploying to Azure App Service or Container Apps becomes a few lines of YAML. Secrets live in GitHub, which is fine for this team size. The marketplace has an action for everything Azure-related.
*   **The Pain Point:** Complex, multi-stage pipelines can get messy in YAML fast. You'll start wishing for reusable components, which *exist*, but it's not as elegant as some other platforms. Also, cost can creep up if you have long-running jobs and you're not using your own runners.
*   **Verdict:** Low cognitive overhead, fantastic Azure fit. Probably the frontrunner for a team wanting to focus on code, not infra.

**The "We Want Power &amp; Portability" Choice: Azure DevOps**
Yes, it's still here and thriving for a certain use case. Don't let the name fool you—it's a beast of a CI/CD platform.
*   **The Good:** Unmatched pipeline flexibility. The classic "builds &amp; releases" UI is actually great for visualizing complex deployments. Native Azure integration is, of course, perfect. If you foresee branching out to .NET or complex container workflows later, it handles it with grace.
*   **The Pain Point:** It feels like *another* platform. If you're deep in GitHub/GitLab already, switching context to the Azure DevOps portal is a mental tax. The YAML syntax is its own flavor, which is a minor but real learning curve.
*   **Verdict:** If you're a Microsoft shop already using other Azure services heavily, it's a powerhouse. For a pure Node.js/5-person team, it might be overkill.

**The "We Might Leave Azure Someday" Option: GitLab CI/CD**
My personal favorite for philosophy. It treats CI/CD as a first-class citizen, not an add-on.
*   **The Good:** The `.gitlab-ci.yml` file is incredibly powerful. The auto-devops features can get a Node.js app deployed to Azure Kubernetes with shockingly little config. Their security scanning and container registry are baked in beautifully.
*   **The Pain Point:** You need to manage the GitLab &#x2194; Azure connection yourself (service principals, etc.). It's not hard, but it's an extra step. If you're not using GitLab for source control, this makes less sense.
*   **Verdict:** Provides the most complete and portable CI/CD framework. If you value a single pane of glass for code, CI, security, and container registry, it's stellar.

**The Wildcard: CircleCI**
Still a beautifully engineered product, especially for Node.js.
*   **The Good:** The configuration is clean, logical, and their orbs (shared config packages) are fantastic. The Azure orb would handle all your authentication and deployments cleanly. Performance is top-notch.
*   **The Pain Point:** It's *another* SaaS, another place for secrets, another bill. For a small team, the simplicity of an integrated platform (GitHub/GitLab) often wins over a best-of-breed tool now.
*   **Verdict:** If you prioritize a pristine developer experience and elegant config, it's a strong candidate. But ask yourself: is the marginal gain worth the context switch from your code host?

My migration war story? Moving from Jenkins to GitLab CI. The pipeline translation was straightforward, but the secrets migration... oh boy. A week of rotating every single key, credential, and token because we treated the migration as a security reset. The actual pipeline rebuild took two days. The secrets saga took five.

So, for your team? I'd lean **GitHub Actions** for sheer simplicity and focus. But if anyone on the team has deep GitLab experience, or you dream of a more unified platform, **GitLab CI/CD** is a very, very close second.

What's everyone else seeing? Any Azure-specific horror stories or smooth-sailing wins with these tools?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>crm_hopper_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/top-ci-cd-tools-in-2026-for-a-5-eng-team-shipping-node-js-on-azure-2/</guid>
                    </item>
				                    <item>
                        <title>Showcase: Grafana dashboard monitoring migration progress and stability.</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/showcase-grafana-dashboard-monitoring-migration-progress-and-stability-2/</link>
                        <pubDate>Sun, 23 Aug 2026 18:30:47 +0000</pubDate>
                        <description><![CDATA[Hey everyone! New here, but I&#039;ve been deep in a CI/CD migration lately. We moved from Jenkins to GitHub Actions for our main web app.

I set up a Grafana dashboard to track everything during...]]></description>
                        <content:encoded><![CDATA[Hey everyone! New here, but I've been deep in a CI/CD migration lately. We moved from Jenkins to GitHub Actions for our main web app.

I set up a Grafana dashboard to track everything during the switch. It was super helpful! I tracked build times, failure rates, and even deployment frequency. Seeing the new pipeline's stability improve week over week was a huge relief.

Has anyone else used dashboards like this during a migration? What metrics did you find most useful? I'm curious if I missed anything crucial.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>emmam4</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/showcase-grafana-dashboard-monitoring-migration-progress-and-stability-2/</guid>
                    </item>
				                    <item>
                        <title>Walkthrough: Replacing complex Jenkins email-ext templates with a simple script.</title>
                        <link>https://communities.stackinsight.net/community/ci-cd-migrations/walkthrough-replacing-complex-jenkins-email-ext-templates-with-a-simple-script-2/</link>
                        <pubDate>Thu, 20 Aug 2026 17:51:12 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b;

I wanted to share our team&#039;s recent journey of untangling ourselves from a particularly gnarly Jenkins setup. For years, our build notifications relied on the venera...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b;

I wanted to share our team's recent journey of untangling ourselves from a particularly gnarly Jenkins setup. For years, our build notifications relied on the venerable `email-ext` plugin with a set of templates that had... evolved. They were complex, nested with conditional logic for different branches and failure types, and had become a genuine pain point. Every time we needed to tweak the formatting or add a new project, it felt like deciphering an ancient scroll. &#x1f605;

We decided to migrate this notification layer out of Jenkins entirely during our move to GitLab CI. The goal was to replace hundreds of lines of Groovy template code with something maintainable, portable, and simple. Here's the step-by-step walkthrough of how we did it.

**The Old Pain:**
Our `email-ext` templates were doing too much:
*   Constructing HTML tables with build status, commit messages, and test result summaries.
*   Branch-specific logic (e.g., `main` branch failures got a different audience than feature branches).
*   Embedding links to artifacts and specific failed test logs.
*   All of this was stored in Jenkins' config files, opaque to most of the team.

**The New Simplicity: A Small Python Script.**
Instead of translating the templates, we wrote a single, focused Python script that our GitLab CI pipeline calls at the end of every job. The script's only job is to gather the context GitLab already provides and format a clean Slack message (we switched channels, but email would work the same).

The magic is in using the CI platform's native environment variables and metadata. For example:
*   `CI_PROJECT_URL`, `CI_COMMIT_SHA`, `CI_JOB_STATUS` give us the core "what happened and where."
*   We use the GitLab API (with a `$CI_JOB_TOKEN`) to fetch a few extra details if needed, like the commit message.
*   The script then structures this into a straightforward JSON payload for Slack's webhook.

**Key Steps in the Migration:**
1.  **Audit &amp; Prioritize:** We listed every piece of information our old emails contained. We asked: "Who *actually* uses this?" We cut about 40% of the data points immediately.
2.  **Script Prototyping:** We built the script locally, using env vars we simulated. The core logic is just string formatting and a few `if` statements.
3.  **Secrets Migration:** The Slack webhook URL moved from Jenkins' credential store to GitLab's protected CI/CD variables. This was a simple copy-paste with improved access controls.
4.  **Pipeline Integration:** We added one line to our `.gitlab-ci.yml` in an `after_script` block to call the script, ensuring it runs even on job failure.
5.  **Phased Rollout:** We tested it on a low-traffic project first, then gradually updated pipeline templates across our repos.

**How Long It Actually Took:**
*   **Planning &amp; Audit:** 2 days (spread over a week)
*   **Script Development &amp; Testing:** 1 day
*   **Pipeline Updates &amp; Secret Migration:** 1 afternoon
*   **Full Rollout Across 30+ Projects:** 1 week (done incrementally)

The result? A script under 100 lines that anyone on the team can read and modify. It's version-controlled alongside our code, and it's completely agnostic of the CI runner. If we ever move platforms again, this notification script comes with us for free.

Let me know if you've tackled similar legacy notification systems—I'd love to hear what you replaced them with!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/ci-cd-migrations/">CI/CD Migration Stories</category>                        <dc:creator>amyt5</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/ci-cd-migrations/walkthrough-replacing-complex-jenkins-email-ext-templates-with-a-simple-script-2/</guid>
                    </item>
							        </channel>
        </rss>
		