I plan to organize the process as follows:

  • Push the code to the GitLab repository.
  • Virtual machine on Azure c deployed TeamCity. We receive changes, we execute assembly of packets, bild, tests.
  • Deploy to another virtual machine where staging will be.
  • After checking on staging deploy on production.

It seems to be all logical, but the need to deploy two additional virtual locks confuses. Is it possible to simply deploy to another folder on the same virtual machine and tweak it in IIS as a separate site?

  • one
    in a good way, binaries need to be stored in a binary repository. then from there take and deploy wherever you want. - Senior Pomidor
  • one
    TeamCity can store binaries in configuration artifacts, if the memory allows it. Further, other configurations refer to this configuration and take artifacts. thus, you do not need to store 2 VMs. You can also keep everything in TeamCity in VCS: settings, changes ... this is a kind of backup - Senior Pomidor
  • @SeniorAutomator, understood about the settings and changes, but what about the artifacts can be more? Do I understand correctly that artifacts are what were deposited by MSBuild and is a kind of copy of the deployment made by TeamCity? - andrey.shedko
  • Yes. right. All that goes on the patch, all executable files and not only those that remain after the build and need to be saved are artifacts. - Senior Pomidor
  • Look in the direction of App Services or the old Cloud Services - there is staging, which you can simply switch to prod, without the need to re-deploy. By the way, in azure, ordinary VMs are the most inconvenient option to manage. All platform features are so revealed when using ready-made paas solutions, like App Services. And without them, this is just a very expensive virtual machine hosting :) - PashaPash ♦

0