Where a developer loses time without CI/CD, automated tests, and a dev environment

In a team without automated delivery, a developer performs daily non-coding operations: builds the project manually, checks changes by hand, waits for the staging environment to be free, fixes bugs found a week after they appeared. These efforts are not reflected in the tracker: the issue stays in the “in progress” status the whole time. The manager only sees the result — task completion times grow with the same team composition.

This article describes six places where time is lost, how to measure losses over one week, and the order of implementing automation.

Terms

CI (continuous integration) — automatic build and verification of every change pushed to the repository.

CD (continuous delivery) — automatic delivery of a verified build to a staging environment or production.

Pipeline — a sequence of steps described in a file inside the repository: build, tests, code analysis, deployment. The pipeline runs automatically on every change. It is executed by GitLab CI, GitHub Actions, Jenkins and similar systems.

SAST (static application security testing) — finding vulnerabilities in source code without running it.

SCA (software composition analysis) — checking third-party libraries against databases of known vulnerabilities.

Dev environment — an environment where the current version of the application from the main branch runs. QA, product manager and customer review the result there before release.

1. Manual build and deployment

Manual deployment consists of ten to twenty steps: get the code, build, copy files to the server, apply database migrations, restart services, verify the result. One deployment takes from 20 to 60 minutes. The sequence of steps is usually known by one or two people, and the rest of the developers wait until those people are available.

A missed step leads to an outage. Finding the cause takes more time than the deployment itself because there is no action log.

Because deployment is labor-intensive, the team does it rarely. Over two to three weeks dozens of changes accumulate and go to release at once. If something breaks after such a release, the cause is sought among all those changes. When deploying each change separately, the cause is known immediately: it’s the last change.

In a pipeline the same steps are recorded in a file and executed the same way on each run. Any team member can start the deployment. Rollback is done by re-running the pipeline for the previous version.

2. Manual verification instead of automated tests

Without automated tests the developer manually verifies their task and neighboring features that might be affected after every change. Nobody verifies the whole system before release: a full manual check takes days.

A user finds a bug in an untested function. From the bug’s appearance to reporting it takes from several days to several weeks. During that time the developer has moved on to other tasks. To fix it they reread their own code, reconstruct the solution flow, and search for the change that caused the bug. Fixing the same bug ten minutes after the commit takes less time because the developer still remembers the code.

Automated tests reduce this interval to the pipeline duration. Full coverage is not required. The main effect comes from tests for scenarios that bring revenue: registration, ordering, payment.

3. No dev environment

Without a dev environment only the developer sees the result on their local machine. Their machine configuration differs from the server: different library versions, different data, different settings. Some bugs only manifest on the server, i.e., after release.

QA and the product manager get access to the result only after production deployment. Interface and logic remarks arrive when the feature is already available to users. Each remark implies another development cycle and another deployment.

A single shared environment per team partially solves the problem. Developers reserve it in turns, and deploying one branch overwrites the previous changes. Current practice is a separate temporary environment for each merge request (preview environment, in GitLab — review app). The pipeline creates it when the request is opened, publishes the link in the discussion and removes the environment after merging. The reviewer opens the link and sees exactly the change they are checking.

4. Late-discovered vulnerabilities

Without code analysis in the pipeline vulnerabilities are found in three cases: during an external audit, during a customer security review, or after an incident. By that time other features are already built on top of the vulnerable code. Fixing it affects them all and requires rechecking.

A separate case is a password or access key committed to the repository. You cannot remove it with a commit — it stays in history. You have to rotate the key, update it in all systems where it was used, and check access logs for the entire leak period. This takes one to two working days.

Automatic checks in the pipeline include three parts:

• secret detection (gitleaks, built-in GitLab and GitHub tools) blocks a commit with a key before it reaches the main branch;
• SCA (Trivy, osv-scanner, Dependabot, Renovate) notifies about a vulnerable library and creates a request to update the version;
• SAST (Semgrep, CodeQL, GitLab analyzers) finds insecure constructs in code: substituting user input into SQL queries, disabled certificate validation, unsafe deserialization.

The developer sees the remark in the merge request within minutes after pushing code and fixes it as part of the same task. This approach is called shift left: security checks are moved from the pre-release stage to the code-writing stage.

5. Long-lived branches

Without fast automated checks developers merge infrequently. A branch lives for two to three weeks and diverges from main during that time. Merging causes conflicts; resolving them takes hours. Bugs introduced while resolving conflicts remain unnoticed because there are no automated tests.

Trunk-based development practices assume branches that live no longer than one to two days and merging into main in small increments. Incomplete features are gated by feature flags and are not available to users. This approach works only with a pipeline: each merge must be automatically verified in minutes.

6. Waiting and task switching

Each of the points above creates waiting: for a colleague who knows how to deploy, for a free environment, for the result of a manual check, for the reviewer’s answer. During waiting the developer picks up a second task. After receiving the answer they return to the first and spend time restoring context. With several wait periods per day a developer has no continuous work intervals longer than an hour.

The DevEx model (Noda, Story, Forsgren, Grayler, 2023) describes developer productivity by three factors: feedback speed, cognitive load and ability to focus continuously. Lack of automation worsens all three. Feedback arrives in days. The sequence of manual operations must be kept in memory. The workday is fragmented by waiting.

Impact of AI assistants

With an AI assistant a developer writes code faster and the number of changes per unit time increases. Manual verification and manual deployment speed remain the same. The queue of unverified changes grows and delivery time becomes determined by verification and deployment.

DORA reports for 2024 and 2025 record this dependency. Increased AI usage is accompanied by reduced delivery stability in teams without automated checks. The 2025 report conclusion: AI amplifies existing properties of the development process, both strengths and weaknesses. Therefore automated tests and code analysis should be set up before mass adoption of assistants or simultaneously with it.

How to measure losses

Measurement takes one working week. Each developer records in a shared table time spent in five categories:

1. manual build and deployment;
2. manual verification before release;
3. waiting for environments, deployments, or reviewers;
4. fixing defects found after release;
5. resolving merge conflicts.

Example for a team of five developers:

28 hours constitute 14% of the team’s weekly time budget (200 hours). At a developer hourly rate of 2,500 rubles this is 70,000 rubles per week, or about 300,000 rubles per month. The numbers in the example are illustrative. A table with your data gives the sum to compare against the cost of implementing automation.

Time to restore context after task switches is not included in the table, so actual losses are higher than those measured.

Implementation order

Steps are listed in descending order of result-to-effort ratio. Each step gives value independently of the next ones.

1. Pipeline with build and linter for every merge request. This is a single file in the repository: .gitlab-ci.yml or the .github/workflows directory. Duration — one to two days. From this point code that does not build will not reach the main branch.
2. Automatic deployment of the main branch to a dev environment. Duration — from two days to a week, depending on how well the server configuration is documented.
3. Automated tests for three to five revenue-critical scenarios. Tests are added to the pipeline as a required step. Then the rule applies: every defect found after release is closed together with a test that reproduces it.
4. Secret detection and SCA. Both tools can be integrated in a few hours and produce few false positives.
5. SAST with a limited rule set. An analyzer with the full rule set reports hundreds of issues and the team stops reading them. Working scheme: enable high-severity rules, block merges only on them, and add other rules after triaging existing findings.
6. Temporary environments for merge requests. This step requires containerizing the application, so it should be last.
7. Production deployment from the pipeline with manual approval and one-command rollback.

Pipeline duration should be kept within 10 minutes. With a longer pipeline the developer switches to another task while waiting. Main means to shorten it are dependency caching and parallel test execution.

A small team does not need a separate platform group and complex orchestration for this. Signs of overengineering are described in the article about reliability you don’t need.

How to verify the result

Results are evaluated by DORA metrics. All are computed from version control and pipeline data:

• deployment frequency to production;
• lead time for changes — from commit to working in production;
• change failure rate — deployments that required rollback or emergency fix;
• time to restore after a failed deployment;
• proportion of unplanned rework — deployments made to fix defects.

Metrics are recorded before implementation and compared quarterly. After a quarter repeat the one-week measurement from the “How to measure losses” section. The difference in hours multiplied by the hourly cost gives monetary savings.

An additional check is the ramp time for a new developer. With a working pipeline a new hire pushes their first change to production in the first week. Related signs of a process that slows a team are described in the article five signs of infrastructure blocking growth.

Pipeline, automated tests, code analysis and environment setup are part of my services. To estimate the amount of work I need repository access and a description of the current deployment procedure.