Inner versus outer development loops

As discussed earlier, as long as the developer works in their local environment to test things, they are in the inner loop. In general, a developer spends most of their time in the inner loop because it's fast and gives instant feedback. It usually involves the following steps:

1. A developer starts working on a new feature request. Some code changes are done at this point.
2. Once the developer feels confident about the changes, a build is started.
3. If the build is successful, then the developer runs the unit tests.
4. If the test passes, then the developer starts an instance of the application locally.
5. They will switch to the browser to verify the changes.
6. The developer will then trace logs or attach a debugger.
7. If something breaks, then the developer will repeat the preceding steps.

But as soon as a developer commits and pushes the code to a source code repository, it triggers the outer development loop. The outer development loop is closely related to the CI/CD process. It involves steps such as the following:  

1. CI checking out the source code
2. Building the project
3. Running functional and integration test suites
4. Creating runtime artifacts (JAR, WAR, and so on)
5. Deploying to the target environment
6. Testing and repeating

All the preceding steps are typically automated and require minimal to no involvement on the part of a developer. When the CI/CD pipeline breaks because of a test failure or compilation issue, the developer should get notified and then start working again on the inner development loop to fix this issue. Here is a visualization of the inner loop versus the outer loop:

Figure 1.2 – Inner loop versus outer loop

It's very tempting to use CI/CD as a replacement for your inner development loop. Let's discuss whether this is a good approach or not.

Why not use CI/CD?

Contrary to what we just discussed about the inner loop, some developers may say that they don't care about their inner development loop because they have a CI/CD process for it, which should suffice. They are not entirely wrong as these pipelines are purpose-built to make the process of modern application development repeatable and straightforward. Still, your CI/CD process only solves a unique set of problems.

Using CI/CD as a replacement for your inner development loop will make the entire process even slower. Imagine having to wait for the whole CI/CD system to run your build and test suite, and then deploy only to find out that you made a small mistake; it would be quite aggravating. Now, you would have to wait and repeat the entire process just because of some silly mistake. It would be much easier if we can avoid unnecessary iterations. For your inner development loop, you must iterate quickly and preview changes as if they are happening on a live cluster.

We have covered enough basics about the application development inner loop, and now we will cover the traditional application development inner loop for Java developers.