Somewhat new to Azure. We have 3 different cloud service accounts (dev/qa/prod). We have the same 1 web role and 2 worker roles we'd like to deploy to these cloud service accounts. In Visual Studio (2013), I have currently one Azure Project with the 1 web role and 2 worker roles. I have created 3 different ServiceConfigurations for each environment. I can create a deployment package using the corresponding ServiceConfiguration. So far so good.
Now, it seems I can only have one ServiceDefintion.csdef file. If I want different VM sizing for my envs (i.e. different ServiceDefinition.csdef file for each env), how can I accomplish this?
Found various solutions/options:
http://blogs.msdn.com/b/philliphoff/archive/2012/07/02/transform-windows-azure-service-model-files-during-packaging.aspx
Azure: Is there any way to deploy different instance sizes for test/production
However, I ultimately resolved the issue at our deployment server (Octopus). I have a single definition file and 2 config files (local and cloud) - the defaults in VS. For workstation debug the local serviceconfiguration is used. When I build and package I use the cloud serviceconfiguration as starting point. Then in Octopus I transform / variable substitute both the servicedefintion and serviceconfiguration based on target deployment environment.
Related
We have enabled a CI/CD pipeline using azure pipeline. Whenever someone check in to the master, the build should happen and deployment should follow. I wanted to understand how can I disallow someone to deploy to azure function web app from local visual studio
You could use RBAC Rules which may require a lot of config work.
Once you have CI/CD pipeline enabled, setting up RBAC(Role Based Access Control) helps to prevent users from getting the publishing profile, setting deployment credentials etc.,
There will definitely be some config work involved in doing this because you would have to only allow permission to one user so that user could set up the service principal connection between azure and DevOps but also prevent users from creating a deployment user.
I am having 3 “Deploy a Release” steps in a Octopus project. I need to deploy each steps in a different Azure WebApp. How can achieve the this.
For example I have an octopus project named ‘Fruit’, and I have 3 steps in the project, each one to “Deploy a Release”
Step 1: Apple - To be deployed on an Azure Web-app ‘Alpha’ in Dev Environment.
Step 2: Orange - To be deployed on an Azure Web-app ‘Bravo’ in Dev Environment.
Step 3: Mango - To be deployed on an Azure Web-app ‘Charlie’ in Dev Environment.
All the azure web apps are under the same account. Kindly help.
Assuming that you will be having separate package feeds (alpha package,...) for each steps, you should be able to achieve deployment to each web app in same environment by using variables scoped to each specific step.
variable scoping
I'm using Jenkins to produce cspkg files using msbuild. It stores build results in azure blob storage. Then I use management portal to deploy them.
The biggest drawbacks I see are:
1. Deployments can be accidentally deleted easily.
2. There is no straightforward* way to check which version the cloud service has.
Is there a better way to manage deployments?
Its definitely not the best experience is it?
The approach I tend to use is as follows:
Build the deployment package and add the version number to the package filename (taken from AssemblyInfo.cs) e.g. MyCloudService-1.2.0.0.cspkg - this should be trivial using msbuild.
Push the package to Cloud Storage.
Perform the deployment of the package from Storage, with the Deployment Label '[CLOUD SERVICE NAME]-[VERSION] # [DATE & TIME]' e.g. 'MyCloudService-1.2.0.0 # 10-09-2015 16:30'
Check the deployment package into a 'Packages' directory in source control.
If you need to identify the version of the package deployed to the cloud service, you can see the Deployment Label on the Azure Management Portal:
'Old' Portal (manage.windowsazure.com):
'New' Portal (portal.azure.com):
I'm currently running a web solution , that a deployed to multiple azure cloud web roles , the only difference for each web role is web.config , though I'm trying to automatize the process. I'm using now azure powershell + console application to write web.config before each deploy for a specific webrole. Is there any better way to do this ? Does teamcity or any other tools can achieve this ?
Looks like it is possible for every CI server, not only TeamCity.
Fastest (but not cleanest) way would be to create as many build configurations, as you have web roles, implement web.config transform for it, and let MSBuild do it's magic further by deploying your application, running different build configurations.
We are looking to create a test TFS 2010 server based on our live instance.
One method which has been suggested is to clone the Team Project Collection (TPC) onto to another server - as detailed in this existing answer but I think there are a few additional steps?
In order to get the cloned TPC's GUID reset, I take it we would have to first reattach the cloned TPC in the admin console on the original server then detach, move and reattach on to test Server/TFS instance.
We are not running Sharepoint/WSS but would there be additional config work required on the test server with SSRS - in order for new projects to be created against the cloned TPC?
Are there additional using diffrent AD accounts for services or can all of that be resolved within the admin console on the new server?
Both servers will running on VMWare and on the same domain but different AD accounts would be used on the two servers to help prevent any unwanted interactions between the TFS instances.
I will recommended convert your TFS to virtual environment P2V using SCVMM, see this article,
http://mohamedradwan.wordpress.com/2011/06/23/converting-my-physical-domain-controller-to-a-virtual-machine-p2v/