Adopting DevOps practices, such as continuous integration/continuous delivery, can greatly reduce the amount of time you have to spend on building and testing your applications. Besides building your applications, there are also many other concerns that you can address in your pipelines.

When you start adding more and more tasks to your pipelines, you might run into a situation in which a single execution of your pipeline starts taking too long, sometimes longer than 5 minutes. Note that this a general recommendation for the maximum duration of a CI pipeline. In order to battle this, you might be interested in splitting your solution up into smaller builds and maybe even repositories. To do this, you could build parts of that application in isolation and then use the results of these builds in your main application as ready-built components.

Another reason for wanting to split your solution into parts is the use of shared projects. Imagine that you have two solutions that work closely together: one being a REST API and the other being a client package that you ship to your customers to work with that API. It is likely that these two solutions share at least one project with all the objects that are used for modeling the data that is sent back and forth between the two. Here, you could make a third solution with only the shared project, which you could then use as a package in your other solutions.

Or what if you work at a team that is responsible for maintaining a whole series of solutions and you find that you have complete namespaces that are copied and pasted between these solutions. It is not a desirable situation and one that probably comes with a lot of issues. What if you could write this code just once, build it, package it, and then reuse it in all of these solutions.

To summarize, three reasons for starting to work with packages and artifact feeds are as follows:

• Reducing build and CI times by splitting a larger solution into parts
• Extracting shared components into packages
• Building packages that are used by other teams

In the remainder of this chapter, you will learn techniques for doing this by building packages out of (parts of) your application code, hosting them in a centralized location, and reusing them in one or more other solutions.

In all three scenarios, you might be looking to increase the reusability of the code, but also to reduce the time taken between checking for a change and receiving feedback for that change in the form of automated test results. Before you start breaking up your application, remember that moving part of your solution to a separate component does not always achieve this.

If you break your application up into three components and one remaining main part, make sure that you can build and test these three components completely in isolation, or at least close to 100%. If you cannot test a component of your application in isolation, creating a separate repository and build for that component will actually increase the time between checking for a change and the moment of feedback to you as a developer. Both separate builds might run quicker, but now you need to wait for two builds before you receive any feedback.

As well as this, you have to make sure that making a reusable component out of part of your application makes sense from a conceptual point of view. For example, components that are addressing a cross-cutting concern such as logging libraries or database abstraction layers are great candidates for factoring out to shared libraries. (On a side note, after you have done so, you might also want to consider replacing your own general-purpose libraries with off-the-shelf alternatives where possible.)

However, if splitting your solution into components makes sense, it can bring great benefits.