Continuous Integration (CI) and Continuous Delivery (CD) have become standard practices for software teams aiming to push updates quickly. Many teams rely on GitHub Actions or similar systems to automate builds and deployments. These workflows usually involve building a container image, pushing it to a registry, and then applying Kubernetes configurations on a cluster. While these setups are often functional, they can create a gap between the people responsible for infrastructure and the developers who write the code. This gap can slow down progress because developers might be left waiting for the DevOps team to update YAML files, handle secrets, or troubleshoot environment variable issues.
This process often leads to “ticket ops,” a situation where developers have to file tickets for every small modification or rollback. Over time, these repeated requests can overwhelm DevOps teams and make it harder for new features to reach production. An ideal solution will let developers move quickly while still giving DevOps teams a way to oversee and control deployments across different environments. In this post, we’ll look at why existing solutions like FluxCD, ArgoCD, and pure GitHub Actions scripts can be inconvenient for self-service and how Kapstan aims to offer a more direct approach for teams.
Common Methods for Continuous Delivery: GH Actions, FluxCD, and ArgoCD
GitHub Actions
GitHub Actions is widely used for automating tasks such as testing code, building container images, and publishing those images to a registry. It’s easy to get started: developers push code, a workflow is triggered, and a new container is built. This is a good fit for many smaller projects, but things can get more complicated for large teams managing multiple micro services. Scripts in GitHub Actions may rely on many environment variables, secret tokens, or other parameters that must be set correctly. If a developer needs to tweak memory limits or scaling rules, those changes often require new pull requests in the repository that holds the Action definitions. This can lead to a lot of overhead if developers don’t have the right permissions or aren’t comfortable modifying YAML files.
FluxCD
Flux takes the principle of GitOps and applies it to Kubernetes. All changes to Kubernetes resources are tracked in a Git repository, and Flux ensures that the actual cluster state matches what is in Git. This approach provides a clear history of every change, plus an easy way to roll back if something goes wrong on the cluster. However, it assumes that developers are prepared to edit and manage YAML configurations for each micro service. In many organizations, this can cause confusion when new environment variables, secrets, or scaling rules need to be added. Instead of self-service, developers often pass these tasks off to DevOps engineers who know Flux and Kubernetes well. The result is a queue of tickets and a slower release process.
ArgoCD
Like Flux, ArgoCD is a popular GitOps platform for Kubernetes. It has an appealing web interface to monitor which applications are deployed and the status of each environment. ArgoCD also supports automated rollouts and rollbacks, letting teams quickly revert if something breaks in production. The challenge, again, is that developers still need to deal with Helm charts or raw YAML definitions. Even a small tweak to environment variables might involve editing a values.yaml file and pushing a commit to the GitOps repository. If the change causes a deployment failure, rolling back the cluster might be easy, but the Git repository still needs to be cleaned up to reflect the proper state. Developers and DevOps teams may then have to coordinate fixes to restore the application or environment to a stable condition.
Where the current Continuous Delivery solutions Fall Short for Self-Service:
Ticket Ops Explained
Ticket ops is the side effect of platforms that focus heavily on GitOps without adding a friendly interface for developers. Every time a new secret, environment variable, or scaling parameter is required, developers must request an update. The DevOps team, or an infrastructure engineer, creates a pull request to the GitOps repo, merges it, and monitors the deployment. This process takes time and creates a backlog of tickets. Instead of spending time on broader improvements, DevOps teams often get stuck dealing with one-off developer requests.
YAML and Helm Wrangling
Kubernetes YAML files can be very detailed. Helm simplifies some tasks with templating, but it still requires a solid understanding of Helm’s syntax and structure. Many developers are comfortable focusing on application logic and do not want to spend half their day digging through lines of configuration. This gap in expertise can lead to errors that break deployments. Worse, if developers avoid updating these files themselves, they miss out on real autonomy. The result is repeated handoffs that block continuous delivery.
Rollback Challenges
Both Flux and ArgoCD can handle rolling back a cluster to a previous state, but the Git repository itself may still contain the incorrect changes. This mismatch leads to confusion later, because the live cluster and the repo no longer match. It forces teams to remember to revert or remove the wrong commits in Git. This extra step is easy to forget, especially during a crisis. In a truly continuous approach, the cluster and the repo should never drift apart.
Unintuitive observability workflow for developers
ArgoCD and FluxCD offer some visibility, but details like resource usage, performance metrics, or even basic logs can be limited or require external tools. Developers may need to jump from their IDE to an observability dashboard, then to the GitOps repo, and maybe even SSH into pods. That’s a messy workflow. If the platform offered a single pane to see the status of deployments and logs, many tasks would be much more straightforward for developers.
The Need for a Better Continuous Delivery Experience
The next evolution of Continuous Delivery should involve a blended approach: an interface that developers can trust, guided by rules and best practices that DevOps sets in place. This approach makes the overall workflow smoother, with fewer broken deployments and fewer back-and-forth chats to fix small issues.
Kapstan combines the benefits of GitOps with a direct user interface for developers. Instead of requiring developers to learn every corner of Kubernetes YAML or Helm charts, Kapstan lets them manage environment variables, secrets, scaling parameters, and more through a friendly UI. Under the covers, there is still a Git-based approach for version control. This means DevOps teams can keep the benefits of auditing every change, but developers don’t have to file a ticket each time they need to bump their microservice’s memory limits.
How it works
Behind Kapstan’s interface is a layer that syncs config changes back to a Git repository. This ensures a permanent record of who made each change and when. Whenever a developer saves a new configuration for a service, Kapstan updates the Helm chart or YAML in Git. The platform then applies that updated config to your Kubernetes cluster. If there’s a failure, Kapstan rolls back the application version and the helm chart. This method addresses the mismatch that can happen when a GitOps tool reverts the cluster but leaves the repo in a bad state.
Control for DevOps + Flexibility for Engineering
DevOps teams still maintain control over base templates and security policies in Kapstan. For instance, they can define what environment variables can be changed or the maximum scaling limits allowed. Developers then see these fields in Kapstan’s UI and update them if they need to. This approach cuts ticket ops down significantly because developers can handle routine tasks themselves. When a bigger change is needed—maybe hooking into a new service or introducing a fresh Helm chart—DevOps can step in to update the base configuration.
Continuous Deployment with Kapstan: An Example
Engineering Workflow
Imagine a developer wants to add a new feature to an existing micro service. They push their code to GitHub, and GitHub Actions builds the container image. Once the image is ready, they open Kapstan and see their service listed with the latest image tag. They choose the image to deploy, update an environment variable for the new feature, and click “Deploy.” Internally, Kapstan CD syncs all configuration changes to the Kubernetes cluster. If something happens to go wrong, developers are a single click away from viewing logs, metrics, or rolling back changes.
DevOps Workflow
Meanwhile, the DevOps team sets up the baseline configurations for that micro service. They have control to define everything (e.g., CPU and memory ranges that developers can pick from, the allowed environment variables, access to add Secrets). This governance layer ensures that DevOps members control the configurations developers are allowed to modify. The result: fewer misconfigurations and less time spent debugging problems caused by random changes to Helm or YAML files.
Practical Benefits of Continuous Delivery for Teams
Faster Delivery. By cutting down ticket ops, developers release features or fixes whenever they’re ready. There’s no waiting for an overworked DevOps engineer to review or merge a pull request for a minor update. The overall pace of the team increases, and updates can reach production sooner.
Empowered Developers. Developers gain the freedom to adjust their own environment variables, secrets, or scaling rules. This autonomy encourages ownership and helps teams quickly respond to issues or new opportunities. A typical advantage is fewer mistakes, since developers are the ones who best understand the application’s requirements.
Reduced DevOps Burnout. DevOps teams spend less time on repetitive tasks. They can focus on strategic goals, like improving platform reliability or exploring new technologies that help the business. Instead of reacting to a flood of tickets, DevOps can design guidelines in Kapstan and trust developers to handle day-to-day changes.
Continuous Delivery Conclusion
DevOps solution that helps engineering teams provision, configure and deploy complex cloud infra+apps in their own cloud account, in minutes. Our goal is to offer engineering teams a self-service experience to deploy and configure microservices, databases, jobs, and more - without the need for ticket ops. We bridge the gap between DevOps and application teams, to maximize Developer Experience and lower operational costs.
If you’re curious - you’re welcome to try Kapstan for free. Let us help you with the infrastructure wrangling, so you can spend your time more effectively.
