In this episode, Jeffrey is going to show you how to properly package release candidates of your application and prepare them to be deployed to a representative environment, a pre-production environment, that will eventually go to production. In order to have something to deploy, it needs to be packaged in the proper manner.
Code sample: https://github.com/jeffreypalermo/onion-architecture-dotnet-6/
First, you will create a release candidate with a version number using the proper pattern: major.minor.build.revision, and integrate that into your build. You will learn how to modify the build script for the build script to have the logic necessary to create deployable packages from the built code. You will then learn how to archive the files that are a result of this process into a package manager to produce the release candidate.
A release candidate is a concept with multiple files and a particular version of a particular application. This can be composed of one or multiple files and one or multiple deployable components. In this example, the application has a website and database that will be packaged up, including the full system acceptance test suite. This will allow you to run the test suite in a fully deployed environment. This means there will be three things you will need to package and three things that are going to be deployed and operate in a production-like environment. They will all be stamped with the name of the application, the church bulletin in this example, with the version of the application that comes from the build number.
You will also be introduced to proper build numbers- dot net, dot exe- to have the right files to package up. You will learn about a tool called Octopus CLI to package up the three components into NuGet packages ready for deployment.
When archiving the release candidates, you will use Azure Artifacts in the full NuGet server to provide a safe, secured, and available location whenever the deployment tooling needs to grab a specific version or a specific deployable component.
