Why CI/CD pipelines can't replace local software development operations: Managing expectations vs. reality

One of the most complex aspects of development environments is that the software to be developed should usually be part of the development environment itself and developers with a local build process run the software on their local computers.

This is often a major challenge, especially for server software that is not designed to run on “normal” computers. Many companies therefore place high hopes in automated CI/CD pipelines: these enable the software to be developed to be installed on a remote server via a fully automated process.

This often leads to the expectation that local operation of the software to be developed will become obsolete: If developers can deploy the software remotely in an automated way, this would no longer be necessary, right?

Unfortunately, this is a false hope. If developers had to commit the change immediately after each code change in their normal way of working and wait for it to pass through the CI/CD pipeline, they would spend a large part of their time waiting. In addition, the CI/CD pipeline often sets steps that are omitted in a local build: Code Minimization, for example, or extensive testing that involves components that have not had any changes made to them at all. Also, it is often difficult to access the logs of an automated, remotely running CI/CD pipeline, or few or no logs are written to the remote CI/CD pipeline at all.

Therefore, a CI/CD pipeline does not replace the local operation of the software being developed. It is a fixed component of a comfortable development environment. The CI/CD pipeline comes only afterwards. Nevertheless, to overcome the challenges of running complex software in development environments, Remote Development Environments offer a solution.

Here we describe why developers still need a private instance to run the software they are developing and how CI/CD pipelines and RDEs interact to increase developer productivity.

Table of Contents

What are Remote Development Environments?

Remote Development Environments are remote development environments that provide developers with all the tools they need for their work. This development environment is intended to make the local development environment obsolete.

It is important to note that the term is defined differently depending on the provider. At Cloudomation, we provide more than just an IDE with a remote backend. The software to be developed also runs in our RDEs.

You can find a detailed description in our article: What are Remote Development Environments?

What does CI/CD mean?

It is very likely that a CI/CD pipeline is in use in your company.

So, here is just a short explanation: CI/CD (Continuous Integration/Continuous Delivery or Deployment) describes a process that is intended to improve software development and deployment.

The “ideal” CI/CD pipeline

With the help of CI, developers have the possibility to have changes to the code automatically executed and tested. This is a dream come true when several developers are working on the same software. This ensures that the application works at all times. Errors can be detected quickly. CD means either delivery or deployment. The goal of Continuous Delivery is to have a code base that is as up-to-date as possible. This means that code changes are tested and merged. Deployment means that the builds are rolled out automatically.

Read more about this topic in our glossary article CI/CD.

Why CI/CD pipelines do not solve the problem with local development environments

CI/CD pipelines are very useful tools to automate and accelerate many steps in the development process. What they cannot do, however, is make the operation of the software to be developed in the development environment obsolete. Why? Here are two examples.

Example 1. Only the CI/CD pipeline is used

Imagine the following situation: A developer named Lisa works in your company. Lisa develops locally on her laptop. To do this, she has to clone or pull the latest version from the repository. Then she works on the source code and commits and pushes every change. From here, the pipeline takes over to test, merge and automatically deploy / install the code on the internal (sometimes external) systems. Only when the pipeline has run completely through can Lisa connect to the newly deployed system and see, whether her changes have worked or not. So she has to wait for the pipeline to run until she gets feedback for her development work.

In this example, every code change would result in a pass through the pipeline. So if there are 100 code changes, there will be 100 pipeline passes. Now imagine that again for 30 developers. Pipelines can lead to enormous time savings, but like a pipe, only a certain amount can be processed. Above a certain threshold, a bottleneck is created. And with that we have just created a new bottleneck. This exists both in the pipeline itself and in the environments into which it is deployed: if all developers deploy with the same CI/CD pipeline into a shared development environment, it becomes very difficult for the individual developers to determine whether and which bugs were caused by their changes or by a commit from a colleague.

Debugging would also be limited and inefficient for Lisa. Debugging allows her to go through the code step by step to understand the behaviour of the application and fix bugs. The process is iterative, so a change is constantly made to the code until the desired behaviour is achieved (With a pipeline only: Madness! See above). What happens when working with only one CI/CD pipeline? When errors occur, there is often an error message or logs, but these logs do not offer the possibility to debug the code interactively and often do not contain all the information needed. Troubleshooting would become massively more difficult for Lisa.

Lisa quickly becomes dissatisfied with this situation. To get her work done faster, she installs the software to be developed locally. She starts writing scripts that allow her to do a build locally that is customised according to her needs. Instead of waiting for the CI/CD pipeline, she now spends a lot of time maintaining her local build and running the software to be developed locally – probably even more time than she spent before.

Lisa is not happy with this situation either. But how could things be different?

Example 2: Working with RDEs and a CI/CD pipeline

Same situation: Developer Lisa is working on her laptop again. This time, however, with a Cloudomation RDE as her development environment.

She now has the possibility to test her code changes immediately and without a pipeline run. The software to be developed runs in the RDE, along with all her other development tools. On the RDE, she can create the software to be developed with her locally-optimised build. Since RDEs are available on servers and these are individually equipped with the required resources (CPU, RAM, etc.) compared to laptops, Lisa’s waiting time for builds and tests is reduced. Since the RDEs are standardised, Lisa uses the same locally-optimised build as all her colleagues. She no longer has to worry about whether the build of the software to be developed works or not – maintenance of the RDEs and tools on them is centralised.

And: The similarity of the RDEs to the production environment reduces configuration errors. The CI/CD pipeline is not started until it is satisfied with your changes. Lisa receives immediate feedback when an error occurs and can debug as usual. Only then will the pipeline be run, ensuring that further testing is carried out and the software is deployed to a staging environment. Furthermore: If Lisa has to perform a version change, she simply changes the RDE, in which all dependencies etc. are configured again and the correct pipeline is available.

Now you may be asking yourself why not just continue to work in the classic way with the local development environment. This is of course possible, but not practical. Each time, the setup has to be gone through in order to set up dependencies / tools and install the company’s own software. Individual problems that occur in the local development environment have to be solved all the time. With RDEs, standardised environments are available. Setup time is reduced from hours, days or even weeks to a few minutes / seconds – as reported by e.g. Slack or Uber, which already rely on Remote Development Environments and are enthusiastic about the benefits. Maintenance becomes easier because it can be taken over by the DevOps team and each developer no longer has to solve problems individually.

Conclusion

CI/CD describes a process to optimise software development and deployment. Since with the pipeline the software is provided on a remote server, this sometimes leads to a fallacy: namely, that the installation and operation of the software to be developed in the local development environment can be replaced with it. Unfortunately, this is not true.
RDEs offer developers all the tools they need for their work – in a remote environment. With Cloudomation, the software to be developed is also executed in this environment.
RDEs and CI/CD pipelines complement each other: developers need their own isolated development environment in which the company’s software runs. This allows changes to be checked quickly and bugs to be fixed immediately – even before the CI/CD pipeline starts. CI/CD pipelines automate code testing, integration and software deployment, but do not replace the development environment. For example, because the pipeline would have to be run through for every code change (keyword: waiting time) and often too little information is available for debugging to be able to meaningfully correct errors.
The CI/CD pipeline is therefore an important tool that speeds up development work. However, it does not solve the problem that developers need their own private instance of the software to be developed for their work. The effort required to operate and maintain the software to be developed in individual development environments can be drastically reduced by Cloud Development Environments.