Should we deploy source code to Umbraco Cloud servers?
I've posted this question before but got no replies. I'm summarising and simplifying in the hope of a response this time :-)
We use Azure DevOps for all our work but host on Umbraco Cloud servers. Our ADO pipeline can compile the code, so question:
Should we deploy (to UC) the source or just the DLLs?
In my view, the source is a greater risk. The former means that we don't have text files just floating around out there. If we keep our source code purely in our Azure servers, then we surely have one less risk with one less possible point of failure?
Not trying to imply anything - just a subjective look at CI/CD because the docs are ambiguous, as they seem to only cater for scenarios where it is purely Umbraco Cloud or non-Umbraco Cloud setups. We have a hybrid setup I suppose.
If you aren't using the built in pipeline for Umbraco Cloud I don't see any reason why you should have your sourcecode there. If you are using the Umbraco cloud pipeline, then yes, that pipeline will need the source code to compile it.
We develop locally and commit to Azure DevOps repo which we then test the PRs of - again locally.
ii) We deploy the changes to UC
We then copy the contents of Master across manually to another local folder containing the cloned repo from the Umbraco Cloud environment development using manual copying of files and a commit + push of the changes.
It was here where I raised the question of "should we exlude the source code files - such as those with the *.cs extension?". My view is yes. My colleague's is no.
iii) We sync content between UC environments
Once those changes are committed and pushed, we preview the changes on the Umbraco Cloud URL. Once the changes are visible, we the use the in-built content sync (Umbraco Deploy?) to sync the changes with the next environment (staging, test, pre-prod, production, etc)
Yes, we had originally tried the scripts found in the CI CD pipeline link you posted, but there is some configuration work pending where we need to amend so we decided to do the process manually of deploy to UC.
I believe that the sample pipeline Azure DevOps script simply copies everything including the *.cs extension files which is the point of the question. We had a lot of exceptions being generated by the Linux VM that is fired up that only recently disappeared so not sure how reliable they are, or fit for purpose.
Well, I guess an argument could be that if you want/need help from Umbraco support, that they'd have easier access to your sourcecode.
But other then that, it's all up to you IMHO. It is however, just my opinion :)
I think that's pretty much the only upside I can think of in the setup you're describing. If you don't wanna reach a bit and say that it's safer to have the code in two repos if something happens to one of them ;)
They do have a pretty solid building chain nowadays. Except it's a bit slow on the restore part...
I appreciate you getting back to me promptly. Yes - I agree that it is a matter of opinion. The pipeline was broken for a whilst (August 2023 to January 2024) and then suddenly seemed to start working. The command line of the VM was throwing a (generic) exception "1" and I never managed to run the commands manually in a Linux VM.
Should we deploy source code to Umbraco Cloud servers?
I've posted this question before but got no replies. I'm summarising and simplifying in the hope of a response this time :-)
We use Azure DevOps for all our work but host on Umbraco Cloud servers. Our ADO pipeline can compile the code, so question:
Should we deploy (to UC) the source or just the DLLs?
In my view, the source is a greater risk. The former means that we don't have text files just floating around out there. If we keep our source code purely in our Azure servers, then we surely have one less risk with one less possible point of failure?
Not trying to imply anything - just a subjective look at CI/CD because the docs are ambiguous, as they seem to only cater for scenarios where it is purely Umbraco Cloud or non-Umbraco Cloud setups. We have a hybrid setup I suppose.
If you aren't using the built in pipeline for Umbraco Cloud I don't see any reason why you should have your sourcecode there. If you are using the Umbraco cloud pipeline, then yes, that pipeline will need the source code to compile it.
Are you using the CI/CD flow for Umbraco Cloud?
If so I don't see why you would need the the source code there.
Thanks for getting back to us.
i) We work on our changes locally
We develop locally and commit to Azure DevOps repo which we then test the PRs of - again locally.
ii) We deploy the changes to UC
We then copy the contents of Master across manually to another local folder containing the cloned repo from the Umbraco Cloud environment development using manual copying of files and a commit + push of the changes.
It was here where I raised the question of "should we exlude the source code files - such as those with the *.cs extension?". My view is yes. My colleague's is no.
iii) We sync content between UC environments
Once those changes are committed and pushed, we preview the changes on the Umbraco Cloud URL. Once the changes are visible, we the use the in-built content sync (Umbraco Deploy?) to sync the changes with the next environment (staging, test, pre-prod, production, etc)
Yes, we had originally tried the scripts found in the CI CD pipeline link you posted, but there is some configuration work pending where we need to amend so we decided to do the process manually of deploy to UC.
I believe that the sample pipeline Azure DevOps script simply copies everything including the *.cs extension files which is the point of the question. We had a lot of exceptions being generated by the Linux VM that is fired up that only recently disappeared so not sure how reliable they are, or fit for purpose.
Well, I guess an argument could be that if you want/need help from Umbraco support, that they'd have easier access to your sourcecode. But other then that, it's all up to you IMHO. It is however, just my opinion :)
I think that's pretty much the only upside I can think of in the setup you're describing. If you don't wanna reach a bit and say that it's safer to have the code in two repos if something happens to one of them ;)
They do have a pretty solid building chain nowadays. Except it's a bit slow on the restore part...
I appreciate you getting back to me promptly. Yes - I agree that it is a matter of opinion. The pipeline was broken for a whilst (August 2023 to January 2024) and then suddenly seemed to start working. The command line of the VM was throwing a (generic) exception "1" and I never managed to run the commands manually in a Linux VM.
Cheers again
is working on a reply...