3

I'm trying to create a CI/CD pipeline for an example prototype. Thus, I've started simple enough to test my infrastructure - I'm using an almost untouched boilerplate of ASP.NET Framework Web App (targeting 4.6.1). The steps I've completed are:

  • App is deployed to an Azure App Service.
  • Its version control is hosted with Azure DevOps.
  • A build pipeline with the following tasks has been created, set-up and tested if it executes (tasks and their order, come from a template):

Tasks used

  • Azure Deployment Options/Settings are bound to the repository DevOps, thus builds are also displayed in Azure, and should be deployed there if successful.
  • The Build Pipeline is bound to the correct repository inside DevOps
  • Builds get triggered by pushing to the master branch

The next step was to verify that a broken build, because of failed tests or any other reason is not deployed to production in Azure. I've created a failing test for this reason.

And this is where I'm left stumped. Builds do fail as expected and the "App Service Deploy" task is skipped, because the build tasks before it have a failure:

Deployment failed

And yet those broken builds still get deployed to Azure and to production without even waiting for the pipeline to finish. I'm verifying that a change has actually happened with small visual updates.

Build started and finished in Azure as soon as a push occurs before the pipeline in DevOps is fully traversed (or even started, if finding an agent takes longer):

Building on Azure

Built

(DevOps still not finished):

And yet the pipeline hasn't finished yet...

What am I doing wrong here? Am I understanding the pipeline wrong? Have I missed a set-up step somewhere? I'm lost.

Edit: As asked by Josh, here's my trigger as well: enter image description here

Edit 2.2 A bit more clarification of my deployment options in my App Service in Azure, related to Daniel's comments:

enter image description here

This turned out to be the issue.

This is the only option I'm allowed to choose when tying my deployment to DevOps. I'm not allowed to choose a pipeline, just a project and a branch. In a tutorial I've compared with, the settings are the same (at least in this menu), but the build does not get triggered from the repository, but expects the pipeline to reach the appropriate step first, which is why I haven't considered it to be the culprit. Is there some additional setting up, I've missed to do, to indicate that it must look for a pipeline, rather than fire straight away from branch changes?

riQQ
  • 9,878
  • 7
  • 49
  • 66
Derptastic
  • 491
  • 1
  • 6
  • 18
  • 1
    Can you share the release pipeline artifact and CI trigger information? – Josh Oct 11 '18 at 13:18
  • @Josh I'm only using a Build pipeline, I haven't set-up a separate Release pipeline yet. – Derptastic Oct 11 '18 at 13:29
  • 1
    Do you have something in your VS Build step that passes MSBuild arguments that deploys the application? Because if it says a task is skipped, the task is **definitely** skipped. So there must be something else running that's deploying the application, and the only culprit I could think of would be VS Build. – Daniel Mann Oct 12 '18 at 16:41
  • @DanielMann That was my initial thought as well, but the weirdest thing is that both processes start in parallel. When I make a push to the master branch both a build in the DevOps pipeline AND a build in Azure portal start concurrently. The build in Azure is done (and the website is updated) before the pipeline even gets to the "Build Solution" step, this is why I removed it from my culprit list. – Derptastic Oct 14 '18 at 10:23
  • @DanielMann My MSBuild arguments: /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\" I'd like to point out three things. 1) **/p:DeployOnBuild=true** might seem like the issue, but as I mentioned, the build on Azure is started as soon as a push occurs, before we even get to this point. 2) Changing it to false, doesn't help. 3) I've inspected a tutorial for the same process with the same steps, and in there it's set to true and still works as expected. – Derptastic Oct 14 '18 at 10:24
  • What do you mean by "the build in the Azure portal"? If you have some other external system hooked up that's building things, that's your culprit. – Daniel Mann Oct 14 '18 at 16:30
  • @DanielMann What I meant is my deployment options in Azure portal (my App Service) are bound to Azure DevOps. In theory, when the build pipeline gets to the Azure App Service Deploy step and it's successful, it gets deployed to Azure which then updates the build for the App Service it's hosting. Except the build gets updated as soon as I push something to the master branch, rather than when the pipeline reaches the appropriate step. I'll update with a screenshot of my deployment options and a bit more clarification. – Derptastic Oct 14 '18 at 18:13
  • 1
    @Derptastic I could be wrong on this (but I don't think I am): The deployment you have set up in the Azure portal is tied to source control only, not your build definition. So every time you commit to source control, two things happen that are totally disconnected from each other and happen in parallel: 1) A build fires off and 2) the Azure website is updated with the version you just pushed to source control. Remove #2 and your problem will go away. – Daniel Mann Oct 15 '18 at 01:28
  • @DanielMann Nope. You were not wrong. A big thank you! =) So in the end, it all boiled down to me being a moron. Would you please post it as an answer, so I can accept it and mark this issue as resolved? And in case anyone comes in wondering why the deployment options were set-up in to begin with: I started gradually, first setting up deployment from the branch directly and then moving to a pipeline (but apparently should've disconnected the first set-up, which I didn't). – Derptastic Oct 15 '18 at 09:54

1 Answers1

2

The deployment you have set up in the Azure portal is tied to source control only, not your build definition. So every time you commit to source control, two things happen that are totally disconnected from each other and start in parallel since they listen to the same repository for changes:

  1. A build fires off in the pipeline.
  2. The Azure website is updated with the version you just pushed to source control, since its deployment options are bound to it.

Remove #2 and your problem will go away. You set the App Service you want updated in the pipeline, you don't need an additional hook in the App Service itself.

Derptastic
  • 491
  • 1
  • 6
  • 18
Daniel Mann
  • 57,011
  • 13
  • 100
  • 120