Best of CI/CD — April 2026

  1. 1
    Article
    Avatar of collectionsCollections·3w

    Ghostty is leaving GitHub over reliability concerns

    Mitchell Hashimoto, creator of Ghostty and Vagrant, is migrating the Ghostty terminal emulator off GitHub after documenting near-daily outages over a month. He cites GitHub Actions downtime and broader reliability issues he attributes to Microsoft's AI-driven platform changes. Personal projects will remain on GitHub, but a read-only mirror will replace the active Ghostty repo. He hasn't chosen a destination yet, evaluating both commercial and open-source alternatives, and hasn't ruled out returning if GitHub demonstrates real improvements.

  2. 2
    Article
    Avatar of bytebytegoByteByteGo·6w

    How Spotify Ships to 675 Million Users Every Week Without Breaking Things

    Spotify ships weekly app updates to 675 million users across Android, iOS, and Desktop with a 95%+ success rate. Their release architecture relies on trunk-based development, a two-week release cycle with a branch cut on the second Friday, and five concentric rings of exposure (employees, alpha, beta, 1% rollout, 100% rollout) to catch bugs progressively. Feature flags decouple code deployment from feature activation, allowing risky features to bake invisibly in production before being enabled. A centralized Release Manager Dashboard aggregates data from 10 backend systems into a single color-coded view. An automated state machine called 'the Robot' handles predictable transitions (like initiating a 1% rollout after 3 AM app store approval), saving ~8 hours per cycle, while human Release Managers handle ambiguous judgment calls. The core insight is that a weekly cadence with fewer changes per release makes speed and safety mutually reinforcing rather than opposing forces.

  3. 3
    Article
    Avatar of astral-shAstral·6w

    Open source security at Astral

    Astral shares the security practices they use to protect their open source tools (Ruff, uv, ty) from supply chain attacks. Key areas covered include: hardening GitHub Actions CI/CD by banning dangerous triggers like pull_request_target, pinning all actions to commit SHAs, limiting permissions, and isolating secrets in deployment environments. For releases, they use Trusted Publishing to eliminate long-lived credentials, Sigstore-based attestations, immutable releases, and two-person approval gates. They also use GitHub Apps to safely handle tasks that GitHub Actions can't do securely, maintain dependency hygiene with Dependabot/Renovate plus cooldowns, and contribute financially and technically to upstream projects. The post includes shareable GitHub rulesets and practical recommendations for other maintainers.

  4. 4
    Article
    Avatar of frankelA Java geek·6w

    A GitHub agentic workflow

    GitHub agentic workflows combine standard GitHub Actions with an AI agent (powered by Copilot) to handle semi-structured or unstructured data tasks. The author describes a real use case: automating the parsing of product release notes to generate upgrade analysis config files — something impossible with deterministic regex-based automation. Key steps covered include initializing workflows via the `gh aw` CLI extension, writing workflows in Markdown and compiling them to YAML, and using a fine-grained `GITHUB_COPILOT_TOKEN`. Practical pitfalls are shared: forgetting to compile Markdown to YAML before pushing, Windows/Linux line-ending issues requiring a `.gitattributes` fix, security concerns around auto-compiling workflows, and the inability to use GitHub Marketplace actions inside agentic workflows. The system prompt used at runtime is also shared, highlighting security hardening and prompt injection defenses.

  5. 5
    Article
    Avatar of bytebytegoByteByteGo·5w

    The Security Architecture of GitHub Agentic Workflow

    GitHub built a layered security architecture for AI agents running inside GitHub Actions, designed around the assumption that the agent is already compromised. The architecture has three independent layers: a substrate layer using Docker containers and kernel-level isolation, a configuration layer that compiles workflows with explicit permissions and keeps secrets physically unreachable from the agent, and a planning layer that stages outputs for deterministic vetting before they affect real state. Key mechanisms include a secretless agent container topology using proxies and gateways, a safe outputs pipeline that enforces allowlists, quantity limits, and content sanitization, and comprehensive logging at every trust boundary. The post also discusses trade-offs: strict-by-default sandboxing limits flexibility, prompt injection remains fundamentally unsolved, and the architecture is complex enough that it may not suit simpler use cases.

  6. 6
    Article
    Avatar of sdtimesSD Times·5w

    Introducing enhancements in Kiro CLI 2.0

    AWS Kiro CLI 2.0 has been released with three major additions: headless mode for running in CI/CD pipelines and automated workflows without a browser (via API key), native Windows support for use in Windows Terminal, and a refreshed terminal UI featuring a subagent experience with progress monitoring, an updated todo list, and a new task list.

  7. 7
    Article
    Avatar of devopsDevOps.com·7w

    How AI is Shaping Modern DevOps and DevSecOps

    AI is increasingly embedded across the software delivery lifecycle, from backlog management to incident response. Measured against DORA metrics, AI can improve deployment frequency, lead time, failure rates, and recovery times by reducing friction rather than adding tools. In DevSecOps, AI shifts security left by explaining findings in plain language, prioritizing vulnerabilities by exploitability, and auto-capturing audit trails. Practical guidance covers how to run a time-boxed pilot, set baselines, and choose AI tools based on workflow fit, signal quality, governance transparency, and DORA impact rather than feature lists.

  8. 8
    Article
    Avatar of octopusdeployOctopusDeploy·6w

    Continuous Delivery Office Hours Ep.3: Branching strategies

    Branching strategy has a direct impact on a team's ability to practice Continuous Delivery. Gitflow is identified as the worst strategy due to its complexity, coordination overhead, and risk of lost bug fixes. Trunk-based development is recommended as the best approach, where all commits go directly to the main branch, complemented by feature toggles, automated checks, and short-lived branches (3 or fewer, under a day old). DORA research supports this, linking trunk-based development and small batch sizes to elite software delivery performance. Team-wide alignment is essential for trunk-based development to succeed.

  9. 9
    Article
    Avatar of cloudnativenowCloud Native Now·4w

    Dockerfile Practices are a DevOps Tax Before They are a Security Concern

    Poor Dockerfile practices create measurable DevOps costs — slow builds, bloated images, and cross-environment inconsistencies — long before they become security concerns. Common anti-patterns include unpinned base images, incorrect layer ordering (copying source before installing dependencies), and missing .dockerignore files. A real-world case study from Hypersequent shows CI builds dropping from 12–16 minutes to 3.5–4.5 minutes and image sizes shrinking 60–75% after enforcing multi-stage builds, dependency-before-source ordering, and aligned caching strategies. DockSec, an OWASP Incubator Project, combines Trivy, Hadolint, and Docker Scout with an AI layer to surface Dockerfile anti-patterns in plain language at the pull request stage, making remediation accessible to developers without deep container expertise.

  10. 10
    Article
    Avatar of codecraftdiaryCodeCraft Diary·3w

    Trunk-Based Development: Your Pull Requests Are Still Too Big

    Large pull requests are a primary bottleneck in software delivery, undermining trunk-based development principles. The post diagnoses why PRs grow too large — perfectionism, fear of breaking things, horizontal work slicing, and slow review culture — and offers concrete fixes: enforce a 300–400 line PR limit, use feature flags to merge incomplete work safely, slice work vertically for end-to-end value, optimize review turnaround to hours not days, and track PR size and lifetime metrics. The core argument is that small PRs are a discipline, not just a technical practice, and that flow must be prioritized over polish.

  11. 11
    Article
    Avatar of codecraftdiaryCodeCraft Diary·7w

    Trunk-Based Development: Why Most Teams Think They Use It (But Don’t)

    Many teams claim to practice trunk-based development but actually run a slower hybrid of feature-branch workflows. Real trunk-based development requires merging to main multiple times daily, keeping PRs small (under ~300 lines), fast code reviews (hours not days), feature flags to safely merge incomplete work, and CI/CD pipelines under 10 minutes. Common failure points include oversized PRs, slow async reviews, fear of merging unfinished code, and missing feature flags. A real-world example shows that enforcing same-day mergeability, a 300-line PR soft limit, and feature flags reduced PR size by 40%, cut review time to hours, and increased merge frequency within three weeks.

  12. 12
    Article
    Avatar of freecodecampfreeCodeCamp·4w

    How I Built a Production-Ready CI/CD Pipeline for a Monorepo-Based Microservices System with Jenkins, Docker Compose, and Traefik

    A comprehensive guide to building a production-ready CI/CD pipeline for a monorepo-based microservices system on a single Linux server. Covers running Jenkins in Docker, using Traefik as a reverse proxy with auto-renewing Let's Encrypt HTTPS certificates, and writing a Jenkinsfile that detects which microservices changed per commit and redeploys only those affected services. Includes full Docker Compose configurations, step-by-step Jenkins setup, GitHub webhook integration, a detailed troubleshooting section covering real production errors (dubious ownership, SSH vs HTTPS auth, missing Compose plugin, timezone issues, pnpm timeouts), and a host-vs-container mental model reference table.

See all CI/CD archives