devops integration

With the site live now, I would like to try one last thing. It would be nice if I could automate the deployment of the site via Devops Pipelines instead of still doing it manually.

It turns out that this is very simple to do. When configuring the build pipeline (first post in this series), I missed out the publish part. If I add in to the build to output it to Azure Artifacts, I can thereby use that published code in a simple deploy pipeline.

I followed this post Configuring CI/CD Pipelines as Code with YAML in Azure DevOps | Azure DevOps Hands-on-Labs as a quick start helper.
Here is the final YAML code:

trigger:
- master

stages:
- stage: Build
  jobs:
  - job: Build

    pool:
      vmImage: 'windows-latest'

    variables:
      solution: '**/*.sln'
      buildPlatform: 'Any CPU'
      buildConfiguration: 'Release'

    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'restore'
        projects: '$(ProjectName)/$(ProjectName).csproj'
        feedsToUse: 'config'
        nugetConfigPath: 'NuGet.config'
        externalFeedCredentials: 'Telerik Feed'
        
    - task: NuGetToolInstaller@1

    - task: NuGetCommand@2
      inputs:
        restoreSolution: '$(solution)'

    - task: VSBuild@1
      inputs:
        solution: '$(solution)'
        msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
        platform: '$(buildPlatform)'
        configuration: '$(buildConfiguration)'

    - task: VSTest@2
      inputs:
        platform: '$(buildPlatform)'
        configuration: '$(buildConfiguration)'

    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'drop'
        publishLocation: 'Container'

- stage: Deploy
  jobs:
  - job: Deploy
    pool:
       vmImage: 'vs2017-win2016'
    steps:

    - task: DownloadBuildArtifacts@0
      inputs:
        buildType: 'current'
        downloadType: 'single'
        downloadPath: '$(System.ArtifactsDirectory)'
        artifactName: 'drop'

    - task: AzureRmWebAppDeployment@4
      displayName: 'Azure App Service Deploy: MyApp'
      inputs:
        ConnectionType: 'AzureRM'
        azureSubscription: 'My Azure Subscription'
        appType: 'webApp'
        WebAppName: 'MyApp'
        packageForLinux: '$(System.ArtifactsDirectory)/drop/*.zip'

There are two stages a build stage and a deploy stage. The build stage zips it and saves to Azure Artifacts. This artifact is then available to use for the deployment process.

In my case with the site being small and only me developing it, I could plug the deploying into the build pipeline. In a situation where there are more developers, or someone needs to approve the deploying process, these two stages could be split into different pipelines and run at separate times.

Conclusion

Having now successfully completed my first publish to Azure, I could see that whilst Azure has amazing powers, it can be used on a low level too. I am still not convinced it is right for small businesses or corporations. It seems to work out quite expensive for small scale. Although one App Service Plan can be used for multiple sites (if resources aren’t an issue), which would reduce the cost.

Series Navigation<< Deploying to Azure – Part 4, Adding a custom domain

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.