I did it myselve ( asp.net mostly).<p>Jenkins with git ( gitlab) connected: alpha, beta and master branches seperately. It can execute batch, powershell, msbuild and .exe files in the user environment.<p>All packages contain nuget publishes to our own nuget server. The versioning is like ( for alpha, beta): {packagename} Version {MajorVersion}.{MinorVersion}{PatchVersion}-{PreReleaseString}{BuildNumber}<p>{PreReleaseString} is removed for the master ( production) builds.<p>All nuget packages are constantly build, including api nuget packages. Just make sure you change the MajorVersion,MinorVersion and PatchVersion when doing newer versions that change features/functionality accordingly. ( mostly isn't required because the incremented jenkins build number).<p>It supports parameters and a publish can choose to include / exclude : database migrations, nuget packages, api and web frontend ( normally, all of them are published/executed)<p>Alpha, beta and master is chosen because of the alphabeticle name. So the beta version appears on top of the alpha version.<p>I created a powershell script, that uses EF-Migrations for multiple databases depending on an auto-generated XML file ( with all connectionstrings in it). So it's server /database agnostic.<p>Powershell also sets the web applications offline/online accordingly. So the user receives a notification on the webfrontend ( we are back soon) and the api gives a 503.<p>The API libraries trigger an error on 503 and it's explained in the documentary for third parties ( One update a month with 30 minutes downtime in the morning from 06:30)<p>Tests happen after the "builds", if the tests fails, the build fails. But nothing has been changed ( database and published code).<p>If the migration scripts fail for a database, a "instable" build is given. Mostly these are manual fixes.<p>The offline html file gives an internal link to a Jenkins build monitor ( for duration estimation). You can see how long it will take till a "normal" finish of a build.