Azure Devops Projects/Repos with Kentico 13

Brandon White asked on November 3, 2020 16:19

Any best practices on how to version the Kentico 13 solutions in Azure Devops? Since it is broken up between 2 solutions - 1 for the admin site and 1 for the live website would you make a project for each in Devops? One project with a repo for each solution? One project and both in same repo?

Correct Answer

Brenden Kehren answered on November 3, 2020 17:41

Hey Brandon. V12 MVC was like this as well. You'll want to have 2 different solutions and sites for this. One for the Kentico Admin and one for your MVC site. I'd recommend NOT having both solutions in one repo. You don't want to have to re-deploy the Kentico Admin simply because you're adding some features on your front-facing site and visa versa.

2 votesVote for this answer Unmark Correct answer

Recent Answers

Brandon White answered on November 3, 2020 20:22

Thanks, that's what I was thinking too. I have them in separate repos now.

0 votesVote for this answer Mark as a Correct answer

Sean Wright answered on November 5, 2020 03:04 (last edited on November 5, 2020 03:08)

We keep both projects in the same repository. We have Azure DevOps configured to do builds based on where the change was in the repositories.

Here's an example of a build pipeline definition for just the DancingGoatCore app:

  batch: true       
    - master        
    - 'src/DancingGoatCore/*'

  name: Hosted Windows 2019 with VS2019

- template: build-pipeline-release-steps.yml
    projectName: 'DancingGoatCore'
    configuration: '$(build.configuration)'

Where build-pipeline-release-steps.yml are the steps shared between projects (if any), or just replace the steps here with all the steps you want.

We would have an additional build definition .yml file for our Content Management (CMS) project.

Since both build definitions only look for changes in specific paths of the repository, completed pull requests will only trigger builds for a project when changes were made to that project. (You can also configure this for CI builds that are run with each push to the PR'd branch - this works the same way and can be configured to only run the specific CI build for each project when changes to that project were made).

This allows for easier sharing of code between the projects and also verifying that the entire solution builds.

Having a solution build is very important when sharing code. These two apps are tied together at the database, and generated custom Page Type classes or Custom Module classes are the code representation of that connection. 1 solution ensures consistent deployments of each application.

0 votesVote for this answer Mark as a Correct answer

Brandon White answered on November 6, 2020 19:04

@Sean - thanks, we are using DevOps for our version control but we are not doing build/deploy from there. We have an on-premise install and using web deploy within Visual Studio from our local > test environment. I'm still trying to figure out the best way to do this. I am trying to look into Octopus Deploy as well.

0 votesVote for this answer Mark as a Correct answer

Sean Wright answered on November 6, 2020 19:52


Octopus is a good option for on-prem because you can host it on prem. Azure DevOps also supports on-prem IIS deploys, but it requires access through the firewall (if you have one). I don't remember if there are agents which support this sort of communication for you.

I worked on a team that used DevOps for Repos and Octopus for Build/Deploy and it worked well. Eventually they shifted to DevOps for Build/Deploy as well because their hosting was App Services in Azure.

In either case, you should be able to limit builds to being triggered by specific paths within your repository. This is the mono-repo approach and while the .NET world has always supported it, other languages/ecosystems have adopted it as well over the past couple of years.

0 votesVote for this answer Mark as a Correct answer

Brandon White answered on November 9, 2020 15:49

Thanks Sean, I looked more into the Azure DevOps on-prem deploy and got it working. There is an agent configured by a PowerShell script that handles the communication behind the firewall.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.