How to setup CICD pipeline for .net core application having different config files for different environemnts in azure devops

Nikhil Rasal 20 Reputation points
2024-04-29T14:52:23.5433333+00:00

I have to setup CICD pipelines for .net core application which has 4 environments Dev/QA/Uat/Prod with 4 different config files such as appsetting.qa.json, appsettings.prod.json etc, need to know the .net core mechanism when it gets deployed to azure app service. I mean which config file it will select at the time of deployment. Does it uses default config file i.e. appsettings.json or do we define the default config somewhere in the code or do we have to define any variable in the pipeline.

Below is the yml pipeline created for it,

pool: 
  vmImage: 'windows-latest'
 
variables:
  - name: 'BuildConfiguration'
    value: 'Release'
 
jobs:
- job: Build
  steps:
    - task: UseDotNet@2
      displayName: 'Use .NET Core sdk x.x'
      inputs:
        version: x.x
 
    - task: DotNetCoreCLI@2
      displayName: 'Restore NuGet packages'
      inputs:
        command: 'restore'
        projects: '**/*.sln'
 
    - task: DotNetCoreCLI@2
      displayName: 'Build the project'
      inputs:
        command: 'build'
        projects: '**/*.sln'
        arguments: '--configuration $(BuildConfiguration)'

    - bash: |
       
       if [ "$(Build.SourceBranch)" == "refs/heads/dev" ]; then

            cp appsettings.Development.json appsettings.json

       elif [ "$(Build.SourceBranch)" == "refs/heads/qa" ]; then
         
            cp ]appsettings.qa.json appsettings.json

       elif [ "$(Build.SourceBranch)" == "refs/heads/uat" ]; then
         
            cp appsettings.uat.json appsettings.json

       else
         
            cp appsettings.prod.json appsettings.json;
       
       fi
         
       
      displayName: 'copy appsettings'

    - task: DotNetCoreCLI@2
      displayName: 'dotnet publish'
      inputs:
        command: publish
        arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'
 
    - task: PublishBuildArtifacts@1
      displayName: 'Publish artifacts'
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'drop'
Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
8,930 questions
{count} votes

Accepted answer
  1. Michael Taylor 60,161 Reputation points
    2024-04-29T16:04:52.8966667+00:00

    In general all the settings files get deployed to all environments. At runtime the default builder will load the root appsettings.json file + the appsettings.<env>.json file based upon the DOTNET_ENVIRONMENT and/or ASPNETCORE_ENVIRONMENT environment variables as discussed here. Hence if you have defined either of these then it loads the environment-specific overload to update any env-specific stuff. For example if you define the envvar to be something then it looks for a appsettings.something.json file and applies it if found.

    If you're targeting Azure App Services then the environment variable is set in your app service's Settings section. Set it there for each environment based upon what you want it to be (e.g. dev, staging, qa, production). If you are hosting on your own server then you have to set it using the control panel. Note that this is generally done at the system level.

    If you, like me, don't like deploying env files for environments that aren't associated with it then add a step into your release pipeline (not the build pipeline you posted) to remove the files that shouldn't deploy. We have a deployment variable defined that identifiers the environment and we remove all files not related to that environment or the root.

    If you are using deployment packages then it might already handle this for you if you can specify the environment. We don't really do to much with deployment packages so I cannot say for certain. Otherwise you'll need to clean up the file after it is deployed to the app service.


0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.