Monorepos, CI and Aspire

[rcollina]

Hello,
Fantastic project. Very excited about Aspire.

Just to add some context: I believe that small-sized monorepos (3 to 5 artifacts tops, an arbitrarily low number) are very useful and enable a super-fast inner loop.

• Great end-to-end debugging experience, you got your Docker Compose running with Kafka and your DB of choice, hit F5 and you're good to go
• No NuGets to share code dependencies across (micro)services - this is a big win to me, both from the operational standpoint of reducing private nuget feeds and/or avoiding polluting publicly available feeds, and also from a governance standpoint; only truly reusable packages - think cross cutting concerns - are published. No app-specific package can be downloaded by another team which might misuses what they find.
• We tend to have an API and a worker setup more often than not, and they're usually worked on together by the same team.

Now, I'm happy to see that Aspire has more than one deployable project in one solution, I think it's the perfect spot.

I'm just curious what would the recommended CI story be - let's say we use a good old GitFlow branching strategy.

Will there be any guidance provided in order to show how to correctly produce artifacts from an Aspire repo?

[DamianEdwards]

The artifacts from an Aspire repo build should simply be:

• The artifacts from the composed service projects themselves, e.g. container images, zip/tar files or published apps, etc.
• The Aspire manifest for the AppHost project

Those two things should give you everything you need to deploy the resources built by your Aspire solution using your deployment toolchain of choice. When using .NET Aspire, the service projects themselves are no different from any other ASP.NET Core project, so they produce the same kind of assets. The key difference is that when using Aspire Components, your projects expect configuration values in specific keys. When composed by the AppHost project, that will all be represented in the Aspire manifest.

[rcollina]

Thank you @DamianEdwards for your reply.

I’m not really concerned about the deployment part for the time being, I’m mostly looking for a continuous integration pipeline example whose output will be deployable artifacts.

[DamianEdwards]

That depends on how you're going to deploy, but at a minimum, you can simply run dotnet publish in the .sln directory, and all publishable projects will be published to their respective publish output directories. If you want to produce containers, you can pass the -t:PublishContainer target or use -p:PublishProfile=DefaultContainer to have the publish build and push container images to the configured container registry (see docs for more details).

/Cc @baronfel

[baronfel]

@DamianEdwards is right - you can specify the target at the solution-level and MSBuild will call that target on the projects in the solution. There are a couple hurdles at the moment that may bite you if you have projects other that web or worker projects in the solution, because today the "PublishContainer" target doesn't exist (even if not callable) for all project types. We're working on that for the next SDK release early in 2024. If that's a big problem you have a few options:

• call publish your self on each project via the CLI
• make a target on the Aspire host to publish each containerizable project only. A very simplistic version of what this might look like is here

I've got a number of different publishes to different container registries in a GitHub Actions workflow here that you can take a look at for an example - they are very similarly structured. The overall approach is a) login to the destination, b) push the container via the SDK. There's just varying amounts of juggling along the way of getting the token to login with. One thing to note is that if you're using GitFlow you probably have a sense of what version you want the app to be. You can pass the ContainerImageTag property to the build (or set it via other MSBuild logic) to have the SDK tag the resulting image with whatever version you want (as discussed here).

[rcollina]

I forgot to mention that indeed I want to produce container images, that was crucial info that was missing - sorry about that @DamianEdwards .

@baronfel can’t speak for everyone of course but our teams would be just fine with just web and worker project types, so that is not an issue at the moment.

The actionable feedback first: do you happen to have a public monorepo with a complex pipeline that includes both static code analysis and security tools and release management? One that “builds once” is a big plus.
I’m looking for something more complex than a few steps.

Now, I hope you don’t mind if I bounce some ideas off you, but, as they say, I’d like to learn from the pros.

My typical CI pipeline would look as follows, off the top of my head:

• build all solution projects (with publish), nothing fancy, just build to an output folder
• run all solution tests with a specific tag or tags
• run SAST over the whole solution
• manual step: begin container image production
• create a Dockerfile for each project in the solution
• run some static analysis tools
• create container images using the build output
• run some security tools, again
• publish the container image to a binary repo

I’m building once and reusing the build output throughout the pipeline.

I did gloss over the release management part - creating a release branch from develop would include all in-progress work which is carried over from the integration branch, while I might be interested in creating artifacts just for a subset of the solution projects that are ready to be tested and then pushed to prod. I’m looking for solutions in this space, there seems to be plenty in the nodejs / javascript ecosystem but few-to-none in dotnet.