CPS1 was created to address the need for change in software development practices. Our product directly tackles these challenges and enhances development processes.
We believe that achieving scalability in software delivery requires a centralized approach to managing development environments, moving away from individual work on each developer's laptop.
To understand our vision for CPS1, we must understand the concepts of inner and outer development loops. For those unfamiliar with the terminology, these two phrases refer to different aspects of software development workflow.
The inner loop involves an individual developer's cycle of coding, building, and testing changes. This process occurs on the developer's computer within a local environment, allowing for rapid feedback until the code is ready for review as a pull request (PR).
In contrast, the outer loop takes place after a developer pushes code to a repository. This phase involves merging changes into the main source, usually triggering a CI/CD pipeline that tests and builds the new code, ultimately creating a production-ready artifact for deployment.
While the distinction between the inner and outer loops may seem straightforward, a significant gray area often exists between them. This can create friction in the development workflow that is frequently overlooked by developers.
Let's talk about five common inner and outer loop challenges:
Cumbersome build process
Works on my machine syndrome
Long delays for feedback
Expensive context switching
Configuration drift
Cumbersome build process
The adoption of container based workloads resulted in great gains regarding operations, scalability and increased density and better compute resource usage.
On the developer side though, with the adoption of a cloud native containerized development, the inner development loop usually slows down, because of the need of extra tools and complexity to handle containerized workloads, creating a burden for developers to deal with beyond just the programming language and framework of given application.
Coding stays the same, but it has to be containerized in the build stage, requiring that a developer makes extra steps to test code changes.
The scripts and steps for running a build locally likely differ from your CI/CD configuration. Essentially, this means that the developer is not able to properly build a code change on the inner loop like in production, extending the process all the way to the outer loop.
Examples of these extra steps includes building container images and dealing with Kubernetes, like writing manifests and doing deployments on a cluster. While using tools like kind or K3s may help, it creates a tax on the developer that has nothing to do with coding.
Works on my machine syndrome
Even if a team adopts a specific programming language and framework, the developers of the same team will have various personal preferences on how to configure their local development environment for the inner loop.
If a team has 8 developers, it would not be surprising at all if we find 8 different combinations for running the same application.
Testing in the inner loop may be unfeasible or insufficient because the developer’s laptop doesn't have the required resources or access. Therefore, developers can't validate their code's effectiveness.
Additionally, the inner loop tooling often differs significantly from the CI/CD pipeline, meaning the testing process extends into the outer loop, causing a longer lead time for changes.
Some changes are only verifiable by going through the CI/CD process to build and deploy within a target environment, due to challenges like local system resource limitations, staging environment requirements, or network access needs.
The outer loop becomes a dependency for reliable testing and a dependency for inner loop work.
When the outer loop is considered, we constantly see developers using various workarounds along with a list of undocumented processes to get their work done and move to the next task, due to various constraints limitations on what can actually be done on their local development environments, compared with a dev/staging environment.
Long delays for feedback
While in the inner loop, the developer typically codes, run, tests, debug, before it changes can be presented and shared with other teammates.
After a developer finishes a given task, the outer loop usually starts with code sent off for integration, including code review and a series of other tasks defined on a CI/CD pipeline, only then to finally being deployed to a dev/staging environment for further testing and QA validation.
This typical workflow results in team interactions taking longer due to their dependency on the outer loop.
Developers don't share their work while in the inner loop, so other team members can't see it until it is pushed to the outer loop.
Valuable feedback is delayed waiting for CI/CD pipelines, which delays work and slows releases into production.
A common scenario is frontend developers have to wait for previews of backend changes on a shared staging environment or rely on mocks and stubs. On the other hand, the backend developers have to wait for CI/CD pipelines to build and deploy to verify that their code works correctly when cloud-based dependencies exists.
It is not surprising that in most companies, there are certainly various changes that can be minimally tested only after being deployed in some sort of dev/staging environment.
Expensive context switching
When the development workflow reaches the outer loop, that’s where the more severe bottlenecks happen, often waiting for other teammates to move the development process further, specially code reviews.
Developers favor code reviews as one of the best opportunities for sharing knowledge and increasing overall quality of the codebase.
Code reviews happen in the outer loop, and it's common that the process eventually becomes a bottleneck for various reasons. One of the causes is that the reviewers have to change their local development environment to properly run the application and comment on the new code changes.
The author of a merge request might start another task while waiting, which will cause more context switches. This back and forth between the inner and outer loops causes delays until the code is actually ready to be integrated.
Configuration drift
Making the inner loop (local development), outer loop (remote environments and CI/CD) and production environment consistent and predictable is absolutely painful and hard.
The tool chain for the inner loop is normally setup totally differently from the tool chain in the CI/CD pipelines.
Quoting Matt Rickard, creator of the tool scaffold:
A good inner dev loop is both fast and correct. It’s easy in theory to get “correct”: work in an environment as close to production as possible and run a production build and deploy loop on every change. That’s usually too slow. “Correct” is so important because it prevents reproducibility bugs that are notoriously hard to track down and fix. - The Dev Inner Loop
Making the inner loop correct and fast as Matt stated is not easy. Usually the inner loop will be optimized for fast feedback of changes instead of a more production-like configuration, by leveraging performance improvement tools, such as background building in the IDE or automatic application reloads after rebuilds. This ensures that there is no need to wait by the time a developer switches contexts, like moving from the IDE to the browser for testing.
This in turn means you cannot have confidence that changing any development configuration on the inner loop will not affect the outer loop, like the CI/CD pipeline and the production environment.
How CPS1 impacts inner and outer development loops
CPS1 is a solution that simplifies the transition of cloud native software development from laptop-based local environments to the cloud. It is available as a pay-as-you-go SaaS or as an installable option in your cloud account.
By intelligently and automatically managing and allocating resources, CPS1 enhances your whole development process, eliminating the constraints and limitations of traditional laptop-based setups, resulting in a faster workflow.
Key feature: on demand workspaces
CPS1 creates on demand and isolated workspaces using our detection technology that can instantly inspect your code, and precisely define requirements like programming languages, frameworks, databases and much more, without the need of any manual configuration.
The workspace provides a seamless Developer Experience to code, build, and test complex applications, including microservices, without relying on CI/CD pipelines or deployments to staging environments for proper testing.
The only requirement is a web browser, where the developer accesses a Visual Studio Code IDE integrated with their workspace.
Key feature: automated preview environments
Each workspace can be used to easily collaborate with teammates, by sharing live and accessible instances of running code, bypassing the need for deployments and intricate network configurations.
Sharing workspaces drastically reduces the lead time to deliver changes, so teammates can review and validate the work done by developers much earlier in the development cycle.
Embrace a more efficient, straightforward development experience by cutting down on costly context switches and reducing multitasking, by making code reviews while your application is actively running.