--- title: "APi Artifacts" url: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/api-artifacts.md" canonical: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/api-artifacts/" tags: [] author: "Roy Osherove" description: "Lesson 8 of 17 in Beautiful Builds and Continuous Delivery Patterns (Team Collaboration Patterns for CI), 6:05. Free video by Roy Osherove." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # APi Artifacts 1. [Courses](https://courses.osherove.com/#courses) 2. [Beautiful Builds and Continuous Delivery Patterns](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/) 3. Team Collaboration Patterns for CI Lesson 8 of 17 Duration: 6:05 [Watch on YouTube](https://www.youtube.com/watch?v=98tWt2G9XWY) ## In this lesson Roy Osherove shows that with many snapshot dependencies between components built by different teams, building one component can mean waiting for the full build cycle of every component it depends on, because each tip invokes all the steps before it. The API artifacts pattern, which he credits to Ståle from one of his projects, adds a public API build configuration at the start of each component's chain that compiles only the component's public APIs, without tests, so others can depend on it within seconds. The system integration build still has snapshot dependencies on every tip, so deployment only uses components that pass all their tests, and the CI build copies the public API into its artifacts so it is not compiled twice. ## Transcript 964 words [\[00:03\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=3s) Hi everybody. Today we're going to talk about a problem that happens when you start using a lot of snapshot dependencies when you have a lot of inter-team dependencies. And that is that the build can take a long time. And I'm going to show exactly how that happens. And one possible pattern that we can use to make things go faster. I call this pattern API artifacts and it was actually the guy who came up with it was working in a project that I was working on. And he is the basically the one who came up with with this whole idea. [\[00:35\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=35s) So a tip hat tip to Ståle from one of the projects that I've been working on. So let's imagine that we have this inter-component dependencies and components are developed by multiple teams. But each component requires the binary version of the other components. So component two requires component one, which in turn requires component four and three. Component four itself also requires component three. [\[01:06\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=66s) So with all that said we might end up with something that looks like this. We have for each component its own little parallel universe as we've seen. Each component has its own build chain and each component also has a tip build configuration, which we use to get the latest and best artifacts from the component after having been through all of the tests. Now [\[01:41\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=101s) If we do have that and let's say we want to have component two built, this is the dependency graph we're going to have. Okay, to build component two CI, then we would need the tip of component one, which requires the tip of component four and three, etc. etc. Now this kind of looks okay. Unfortunately, if you remember a tip, it has a snapshot dependency on all of the steps before it, which means that when you invoke the tip build, it will it might actually invoke all the steps before it, and that might take a long time if all of the step the steps actually have to run. [\[02:17\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=137s) So, instead of just running the tip, we actually run all the steps for each component. And that means that to build component two, we might need to wait a full cycle for component one, four, and three. That is way too long to wait. As someone said, the time to wait is too damn high or something. So, how do we fix this? So, we can add a new build configuration at the beginning of the build cycle for each component. [\[02:47\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=167s) And we call this public API. I just called it five because I might end up putting even more stuff before or after it. But I want it in terms of flow, I want it to see the ordering. Now, the public API will compile and build just the public APIs for a specific component. For example, you would separate the component's public APIs from its logic, and then only build that specific DLL or JAR file or whatever it is. [\[03:19\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=199s) And then those public APIs get compiled really fast, but we don't run any tests for them because they're only public APIs. And so, then others can consume them very, very quickly, and only then do we build the CI and unit test integration and tip. So, now the dependency graph looks like this. To build component two, I need just a public API build of component one. That might take maybe just 20 seconds. I don't have to wait for the CI and unit test and integration test, etc. And which in turn only has to wait maybe 10, 20 seconds for each other component, which makes the builds much, much faster. [\[03:55\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=235s) Of course, that means that we might end up getting a What we care about is that component two gets the latest version of the public APIs that it's using. Because each component hand has its own little build cycle and build chain, if that component ends up not working correctly, that component's build will end up failing, and the end the the final build and deploy cycle for all the components together will fail. But to build a specific component, I don't have to wait a long time. If we look at the bigger picture, it might end up looking looking like this. [\[04:29\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=269s) At the bottom, we can see the deploy chain, and the system integration get has snapshot dependency on all of the tip build configurations, which is what we want, because we want when we deploy something, we want to make sure that all components have been passing all their tests. However, for each component just to build that component to compile, we don't have to get all the tests from all the other components. So, we just get the public API build configuration. If in the system integration we deploy we deploy the tip, the tip will also invoke the public API. [\[05:04\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=304s) One other thing that we might need to do is that in the CI build, we might need to override stuff from public API into CI. If CI is building two projects, both the public API and other logic, it's important to copy public API into CI artifacts, so that the things that are used by other components are also the things that are being published here. We want don't want to compile things twice if we if we have a choice. [\[05:37\]](https://www.youtube.com/watch?v=98tWt2G9XWY&t=337s) So, that's basically it. We have a structure, we have tip build configurations for deploying full system configurations and components, and we have public APIs for inter component dependencies. Which speed up the building of specific components. Just to get things compiling basically. And stay tuned for much more information about more topics. ## Related - [BBBCTC - Branching, Binaries, Builds, Coding and Testing Culture](https://pipelinedriven.org/article/2015/5/30/bbbctc-branching-binaries-builds-coding-and-testing-culture) · pipelinedriven.org Roy on finding a simple way for teams that depend on each other's outputs to share binaries, the problem public API artifacts speed up. - [Using TFS Integrator to manage complex project dependencies](https://osherove.com/blog/2007/1/28/using-tfs-integrator-to-manage-complex-project-dependencies.html) · osherove.com Roy on an infrastructure team releasing APIs that other projects build against, and getting new binaries to those projects. [Previous lesson Tipping Point](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/tipping-point/) [Next lesson Deploy by Proxy](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/deploy-by-proxy/) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/