Publishing Destinations with Source Control

[StormCloud79]

Hello

To save our business significant costs we are moving away from Central so as part of this project we have to have our own source control, as we are a software dev business this in its own right has been fairly straight forward.

We created a git repo in Azure DevOps and testing this connection with a test project all worked fine.

The next step was publishing, we are going to be hosting our sites in Azure Blob Storage, we could use sftp to publish to but it ends up being quite expensive to have the sftp in Azure so we are looking at using a separate repo in Azure to publish the content to, then have a pipeline to transfer to the Azure Blob Storage.

So I have created some test publishing destinations and they all work fine on a separate repo on my machine.

Now here comes the issues / questions:

When we tried on a colleagues machine the general source control for the project all works fine, but the publishing destinations do not show the "remote repository" in them at all and we had to create them, when we did publishing would not work and basically it was telling us to do a pull from that repo first, as we are just publishing to that I don't want to pull anything and only push stuff.

Repo.png

Is there any recommended steps on how to make sure on multiple machines this works properly?

I tried on another machine my end and had the same problem, I then from my local publishing folder C:\flare_test_publish\ took the git files from there and copied to my other machine, I then tried publishing again it worked first time. Surely I shouldn't have to be copying fit files to other machines to make this work?

[NorthEast]

When we tried on a colleagues machine the general source control for the project all works fine, but the publishing destinations do not show the "remote repository" in them at all and we had to create them, when we did publishing would not work and basically it was telling us to do a pull from that repo first, as we are just publishing to that I don't want to pull anything and only push stuff.

I use TFS rather than Git, but I presume they'll work in a similar way.

Anyway, Flare publishes (copies) the output files to the local Destination - Directory. This local Directory must be bound to source control.

That message in your screenshot explains that if the local Directory is not already bound to source control, then you need to create the binding - so presumably you used Detect/New to do this.

Once you have bound the local Directory to source control, then it's going to work the same as any directory bound to source control. After creating the new binding, Flare will initially need to get/pull the files from source control and copy them to the local Directory. Then for each publish, Flare will presumably need to first get/pull the latest files from source control to keep your local files in sync. Then Flare will copy the target output files to the local Directory, and then it can put/push any new or updated files to source control.

Is there any recommended steps on how to make sure on multiple machines this works properly?

I can see a potential problem, because the destination file contains the name of a local Directory on your own PC - e.g. c:\bobs files\flare. As you will have multiple people using the same destination file, that local Directory location must exist on everyone's PC.

We had the same problem with project import (GPL) files, as these contain a local directory path, and it would've been a problem to enforce a fixed directory structure. To solve this, we each set up a mapped drive letter that pointed the Flare project location on our own PC (e.g. F:\ = C:\bobs files\flare\).

[StormCloud79]

Thanks NorthEast for the reply, I think its just going to cause a number of my users major issues.

I think I'm going to maybe handle my publishing outside of Flare and use an Azcopy batch file instead to push the updated changes to Azure Blob Storage instead, it seems more manageable!

[AlexFox]

You can use .gitignore to ensure publish destinations files aren't bound to source control and create them manually on each machine.