A portion of your question appears to be implicitly asking how to build and package up your solution such that it can be deployed to your Azure App Services.
There are many methods of preparing your artifacts, however a typical approach is to produce one or more deploy artifacts (.zip files) with transformed configs specific to each App Service assigned with a specific role; namely: Standalone
, Content Management
, or Content Delivery
.
Binaries are deployed on all CM and CD environments. Binaries (DLLs) are not "activated" until they are referenced by a config with a matching role definition, so I can't think of any reason not to deploy the same set across all CM and CD App Services. It will simplify your build / deploy process.
Assuming you have met those artifact prerequisites, there are various methods of getting your custom code onto your App Services; each of which may affect how you produce your deploy artifact(s) as well:
Octopus Deploy
Modern versions of Octopus support direct deploys to Azure App Services with some great configuration options. It can be a bit tricky to set up, but the key is to follow the documentation to a tee.
More reading:
https://octopus.com/docs/deployment-examples/azure-deployments
Kudu Deploy
Technically the Kudu API is part of the Azure Toolkit, but it's worth mentioning specifically as it's a simple and reliable method of deployment.
Kudu has great tooling interfaces and deploys can be triggered via PowerShell scripts with minimal setup on the Azure Portal side.
Here's a sample PowerShell script for deploying to an App Service:
$username = "`$dev-website-sc902-cm"
$password = "tw13qaolWlvihw9fSBxSzhhxcZsNNtz4Gfrxcn3QYCvxSWu80mfaqhDfT9if"
$apiUrl = "https://dev-website-sc902-cm.scm.azurewebsites.net/api/zipdeploy/"
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username, $password)))
$filePath = "$(System.DefaultWorkingDirectory)\$(SourceAlias)/sitecore_artifacts/website-dev-cm.0.0.1.zip"
Invoke-RestMethod -Uri $apiUrl -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)} -Method POST -InFile $filePath -ContentType "multipart/form-data"
Gotcha about DLL and config deployments
One key concept to remember about binaries is that they are paired with configs. Put some thought into how your deployment process handles file deletion (if at all).
For example, let's say you remove a binary and associated config in source control and you deploy. Does your deploy process delete those files? Should it?
In my experience, manual file deletions relating to binaries and configs can be quite tedious, particularly if you're deploying to many App Services.
Octopus has an option for automating file deletions. On the Kudu side, my current understanding is that it always auto deletes files.