CI/CD Pipeline: A Guide for Development Teams

Friday afternoon, the development team of an online retail company is preparing to release a big new feature they have worked on for three weeks. It is a major release: replacing the payment system. The plan is to deploy Friday night when traffic is quiet, so if something goes wrong, the weekend becomes repair time.

At 11:00 PM, the manual deployment process begins. One developer runs commands in the terminal, another checks the database, the rest stand by in the group chat. Half an hour later, the new application is live. Everyone breathes a sigh of relief. Monday morning, bad news arrives: there is a bug on the checkout page, and a lot of customers failed to pay. The team panics, searching for which change caused the problem. But the release is too big — dozens of changes merged into one, and nobody knows which one is the culprit. It takes three days and two manual rollbacks before the system is back to normal.

This story is not unique. In many teams, release day is the most frightening moment of the development cycle, and all that fear is rooted in one thing: an unreliable manual process. This article discusses the solution — a CI/CD pipeline — in a practical, honest way: what it is, how to build it, what it costs, and where its limits are.

CI and CD: Two Things Often Merged into One

The term CI/CD is often used as a single word, but it combines two different concepts. Understanding the difference helps you design the right pipeline.

Continuous Integration (CI)

Continuous integration means: every time a developer pushes code changes to the repository, the system automatically builds the application and runs tests. The goal is to integrate the work of many people continuously, so conflicts and errors are caught quickly — not piled up for weeks and then exploding near release.

Without CI, the classic pattern looks like this: five developers work on five different branches for three weeks. When merged, everything clashes, the application cannot build, and it takes three days to sort out. With CI, every change is tested as it is submitted, so problems appear in minutes, while the change is still small and easy to understand.

Continuous Delivery and Continuous Deployment (CD)

The continuation of CI: after the build and tests succeed, the system also automatically prepares the application ready for release.

• Continuous delivery means the application is always in a releasable state — deploying to production is just one click or an approval away.
• Continuous deployment means every change that passes all automated tests goes straight to production, with no human involvement.

The difference between the two is not technical but policy: is there a human approval gate before production? Most Indonesian teams start with continuous delivery — automated up to staging, production still requires approval — before considering full automatic deployment.

In short: CI makes small changes continuously merged and tested; CD makes those changes reach users quickly and safely. Together, they transform releases from a "scary monthly event" into a "routine daily process."

Anatomy of a Pipeline: What Happens Inside

A pipeline is the automated flow every code change travels through, from the developer pressing push to the application running on a server. The order of stages can vary, but the general structure looks like this:

1. Trigger

The pipeline starts when something happens: new code is pushed, a pull request is created, or a schedule fires. These rules determine when the pipeline "wakes up."

2. Build

The system takes the latest code, installs all dependencies, and builds the application in a clean environment — not on the developer's laptop, so the result is consistent. This stage answers the most basic question: can this code even be built?

3. Test

The built application is tested. There are several layers: unit tests (small functions), integration tests (between modules), sometimes interface tests too. The pipeline can be configured to stop at this stage if any test fails — meaning the change does not continue its journey.

4. Artifact — storing the result

The build output that passed tests is stored as an "artifact" — a specific version of the application, complete with its version number. This artifact is what gets installed on servers later, not raw code.

5. Deploy

The artifact is sent to environments. The usual order: staging first (for final checks), then production. Each step can be fully automated or wait for approval.

6. Verify

After deployment, the pipeline checks whether the application is actually healthy: does it respond, are errors spiking, is the running version what was expected. Many teams skip this stage, yet it is what separates "deployment succeeded" from "deployment actually works."

Each stage above is usually written as a step in a configuration file that lives in version control alongside the code. This matters: the pipeline is not a secret tool living on some server, but part of the project that the whole team can see, change, and trace.

Why Teams Need a Pipeline

Let us compare two teams working on the same product.

Team A has no pipeline. Every release: gather changes from all developers, build manually on someone's laptop, run tests if there is time, upload files to the server via FTP or a panel, restart the service, and hope. A release takes one or two full working days, happens once a month, and always has a horror story.

Team B has a simple pipeline. Developers push changes → automatic build → automatic tests → automatic staging → one-click production. Small releases happen several times a week. If there is a bug, the change is small, easy to find, and can be rolled back within minutes.

The difference is not just technical convenience. It is a business difference:

• Time to market. A feature finished today can be enjoyed by customers this week, not next month. In fast-moving markets — e-commerce, fintech, mobile apps — this gap often decides who wins.
• More consistent quality. Tests run automatically on every change catch regressions earlier. Production bugs do not disappear, but they drop dramatically.
• A calmer team. Releases are no longer synonymous with overtime and prayers. Team energy flows into building the product, not putting out fires.
• Smaller risk per release. Small, frequent changes are far safer than big, rare ones. If something goes wrong, the impact is small and the cause is easy to find.
• Faster onboarding. New developers can read the pipeline and understand how the system works, without having to ask the person who "knows best."

There is one benefit people often miss: the pipeline is living documentation. The workflow that used to live in one person's head is now written in code, readable by anyone, anytime. When a key person leaves, the knowledge does not leave with them.

Building Your First Pipeline: Step by Step

If your team has no pipeline at all, here is the map for building the first one. It does not have to be perfect; what matters is that the main flow is right.

Step 1: Make sure code is in version control

The pipeline reads code from a repository. If your code is not in Git yet, fix that first. No pipeline without this foundation.

Step 2: Start with automated builds

The first pipeline stage can be just one thing: every time something changes, the system tries to build the application. This alone delivers huge value — the team immediately knows when a change makes the project unbuildable. Pick a simple CI/CD platform (many are free for small teams) and create the first build workflow.

Step 3: Add tests

Put tests into the pipeline: build → test. Start with existing tests; if there are none, write a few important tests for the most critical parts of the application — the parts that break most often or cost the most when they break. A pipeline that runs automated tests is the heart of CI.

Step 4: Automate deployment to staging

Make the pipeline send the application to the staging server automatically after tests pass. Now every change can be tried in an environment close to production, without manual work. The team gets used to seeing the application "alive" every day, not every month.

Step 5: Make production deployment one click

Add a step that sends the same artifact to production, with a manual approval gate. The artifact used must be identical to the one tested in staging — not rebuilt differently. Now production releases are one click away, whenever needed.

Step 6: Add verification

After production deployment, run automatic health checks. If the application is unhealthy, the team gets an immediate alert — and if you are ready, the pipeline can even roll back automatically.

This sequence can be completed in 2-8 weeks for most teams, depending on application complexity. The key point: every step delivers its own value, so the team does not need to wait for a "perfect pipeline" to start enjoying the benefits.

Choosing a CI/CD Platform

The most confusing decision for new teams is which platform to use. There are many options, and all of them can work. The principle: start with the simplest thing that solves the problem, and avoid building your own infrastructure until you truly need it.

Questions that help you choose:

• Where does your team's code live? A CI platform integrated with your repository is almost always the smoothest start.
• Can the team maintain it? Self-hosted gives control but demands someone to care for it. Managed platforms remove that burden.
• Does the pipeline need to run on your own infrastructure specifically? Some applications need builds in specific environments; make sure the platform can accommodate that.

Do not spend weeks comparing features. Choose the simplest option, build the first pipeline, and switch only if a real need is unmet.

Traps That Strike Without Warning

The "perfect pipeline" that never finishes

Teams spend months building a pipeline with every feature — caching, optimization, notifications to five channels — while the main application is still deployed manually. Start with the essentials. A running simple pipeline is worth far more than a perfect unfinished one.

Tests that are just decoration

The pipeline looks green (all tests pass), but the tests do not check anything important. This is a silent danger: false security is worse than no security. Audit occasionally: if there is a bug in production, would our tests catch it? If the answer is no, the tests are not working yet.

Deploying to production differently

The pipeline builds an artifact for staging, but production deployment is done manually another way — for example, uploading files directly. This revives all the old problems: environment differences, forgotten steps, and a process that cannot be repeated. One big rule: the artifact tested in staging must be exactly the artifact sent to production.

Secrets and credentials in code

Pipelines need access to servers, databases, and other services. Handled badly, credentials can leak into the repository. Use the secret management features of your CI/CD platform, never put passwords in configuration files. If credentials ever end up in a repository, treat them as compromised and replace them.

Slow pipelines get abandoned

If a build takes an hour, developers will start avoiding it — pushing changes rarely, letting them pile up. A healthy pipeline must be fast: minutes at the start, with optimization (caching, parallelism) when it starts to feel heavy. A pipeline nobody uses is a dead pipe.

Rollback never tested

Pipelines can deploy forward smoothly, but rollback — returning to a previous version — is rarely considered. Yet rollback is the main safety net. Test rollback periodically, so when it is needed, it actually works.

CI/CD and the Indonesian Production Context

There are specific considerations relevant to teams in Indonesia:

Connectivity and latency. Builds that download dependencies from overseas servers can be slow during peak traffic. Consider local mirrors for dependencies, or runners (the machines that execute pipelines) in a region near you, so builds do not stall during busy hours.

Costs in rupiah. Pipelines run on every code change and consume compute. For small teams, platforms with free plans are usually enough. If using cloud, count runner costs in the budget — some teams are surprised that the pipeline "keeps running" without them noticing. Limit unnecessary triggers and turn off unused runners.

Honest staging. Many teams in Indonesia run "whatever is available" staging servers — lower specs, data unlike production. The result: applications pass staging but break in production. Staging does not have to be as expensive as production, but it must be honest enough: same version, representative configuration, and realistic test data.

Workforce needs. Small teams often have no dedicated pipeline person. The solution is not to wait for hiring, but to choose managed platforms and make sure pipeline knowledge is shared — not owned by one person. If needed, get early guidance from an experienced party, then run it yourself once the flow is stable.

The Real Cost of CI/CD

Realistic figures for the Indonesian market in 2026:

The pattern is the same as DevOps in general: the tooling is cheap; the team's time and expertise are expensive. So the first priority is a simple pipeline used every day, not a fancy one with half its features idle.

As a value comparison: one production incident that eats three days of team time — like the opening story — is worth tens of millions of rupiah in salaries and lost revenue alone, before reputational impact. A pipeline that prevents that pattern is a very sensible investment.

When a Pipeline Is Not Worth It Yet

Let us also be honest about when a pipeline is not yet necessary: experimental projects with a lifespan of weeks, applications with no users yet, or code that is still changing drastically. For these situations, a full pipeline can be a burden. But at least apply two things from the start: tidy version control and a build that can be run with a single command. This small foundation makes adding a pipeline later smooth, not a major operation.

A boundary often misunderstood: a pipeline is not a replacement for product decisions, good architecture, or team communication. It is a delivery lane — important, but still just a lane. A wrongly directed product remains wrongly directed, only it arrives faster.

Conclusion: The Pipeline Is the Road, Not the Destination

A CI/CD pipeline is not a goal to celebrate, but a road that makes everything calmer: small changes flowing continuously, tests running automatically, releases that no longer frighten, and a team whose energy goes into building rather than putting out fires.

Start with one small change — an automated build alone transforms how a team works — then let the pipeline grow with your needs. Do not wait for perfection; a simple pipeline used every day beats a grand pipeline everyone avoids.

If your team needs help building its first pipeline — or reworking one that exists but works poorly — the Kartech team in Bandar Lampung can guide you, from process audit to a running pipeline. We start from the problems you face, not from a feature list. Reach us through the contact page or see our services. For broader understanding, also read our DevOps guide for Indonesian businesses and when you need an IT consultant.