My build is triggered thru Jenkins and does a Octo.exe deploy-release. However, it is deploying to all the tenants that are specified for that Development environment.
I am not sure why that is happening.
you have to pass the argument like --tenant=VALUE in call of octo.exe
Make sure that you have multi-tenanted deployment enable in your project setting.
Related
The Context
I have an on-prem TFS (Azure DevOps) server (version 2018.2) with a single deployment agent installed.
This agent is in a shared deployment group and is used to deploy multiple IIS web applications, each application residing in its own project and release pipeline.
The release pipelines all use an identical flow, running the IIS Web App Deployment module to deploy each application.
In the deployment parameters each application has its own, unique virtual application specified.
The Problem
When one application is deployed, it correctly deploys to its unique virtual application, but all other virtual applications that the agent is configured to deploy even in other release pipelines get overwritten by the one application.
What I have tried
Verified that each virtual application parameter is, in fact, unique in the configs
Verified that the release deployment logs for any given deployment do not mention any extra deployment paths. This is particularly perplexing, because the logs say that the operation correctly deploys to only one virtual application.
Check for any strange IIS logs on the target server
The Question
What are the best next steps for debugging an Azure DevOps issue like this? This is an on-prem server, so I have a higher level of access than if this were cloud hosted.
I am thinking perhaps:
Check the agent version and update it to latest?
Could there be other logs with valuable info? On the target server? On the DevOps server?
I solved the problem. See the written-up process below.
Solution
The problem was not with the deployment module, but rather I had mis-configured the IIS management module that ran immediately preceding each deployment module. Each management module had the same physical path parameter value set for each virtual application, which caused each deploy to overwrite any previous deploy.
Debugging Process
When writing up a corresponding issue for this on github, ironically, there was a link to instructions for troubleshooting AzureDevops, so I started following that document.
I turned on verbose logging on the deployment agent by adding the system.debug variable to the release pipeline and setting it to true.
From this I could see that there were, in fact, no other virtual applications being deployed to
I checked the additional agent logs on the target server under the agent install directory in a directory titled _diag.
This showed that everything was working correctly
Still not convinced, I looked at the source code and found that all the module is doing is running MsDeploy.
This got me wondering if all the deployments were going to the same physical location
Then I looked at my config for the IIS management module and noticed that I had set identical physical paths for each virtual application.
I tested the hypothesis by setting a different physical path for each application, and, yay, the applications no longer overwrote each other!
What does it mean by deploying code from dev to prod environments using Jenkins. Can anyone please help. I currently have the source code in my gitlab. I need to deploy this code from dev env to prod env
Thanks in advance.
Source code present in GitLab is just the files that is needed to create a WAR/EAR/JAR to run the application.
It's the environment files if present which makes the application behave slightly different on each environment i.e. DEV/PROD the data that you see on DEV will not be the same that you see on PROD(application is live), as developers tend to test/modify code/data to ensure that the application works as excepted. This is fine on DEV but is a big no-no on PROD as it will impact business.
Deploying code from dev to prod environments just means building the application with the right environment files e.g DEV points to xyz DB but prod points to abc DB.
All this can be achieved with jenkins and if your project uses maven/gradle then with a single line command you can achieve the above.(A bit of googling will help you here)
If your project doesn't involve Maven/Gradle then you will have to replace the environment file each time a build happens based on a parameter which can be passed from jenkins.
This whole process is part of DevOps culture. In simple terms it looks like this:
Developer pushes changes to source control (i.e. gitlab).
Build server (i.e. Jenkins) automatically downloads latest changes and builds an application (i.e. creates setup files or just the binaries). Usually you run tests (unit, integration, automation tests etc.). If something fails then developers get notified about it. This whole process is called continuous integration.
If everything went right then you can deploy your application to production. This part of the process is called continuous deployment.
It's a common strategy for web apps. For larger projects QA team tests the software and the software gets deployed once QA team approves it.
I've been trying for a week to deploy a webrole to Azure Clous Services without quite getting there.
Here is my setup:
I've got a cloud solution with a cloud project and a MVC application (standard no changes to template yet). Its under source control in Visual Studio Online.
I'm using octopack to try generating the nuget package
I'm using the buildt in nuget repo from Octopus
The Octopus server and tentacle is hosted on a VM in azure
I've created a step-template for my deployment step (see this article)
My plan:
I'd like to have a CI build to a dev-service and a seperate build to push my project to the staging environment and roll it onto the production environment using Octopus.
My problem:
The packages that are produced by Octopack seems to not contain what they should. And I've tried to play around with the nuspec file included in my webrole to get it just right. Something ends up missing either way i try.
Have anyone gotten this to work? I'd appreciate any tips pointing me in the right direction as I've slowly been running out of ideas. So i turn to you my fellow nerdlings for some much needed help.
Regards
ZiGGstern
Correct me if I'm wrong but it looks like you're in need of the octo.exe to automate deployments after build within Visual Studio/TFS Online to your target environments.
I'm trying to focus on this statement:
I'd like to have a CI build to a dev-service and a seperate build to
push my project to the staging environment and roll it onto the
production environment using Octopus.
You can configure within your build-template, using the "Post-Deploy Script Path" a PowerShell script to call the Octo.exe (with an API Key) and fire off a deployment for your desired environment(s). You can customize this per build if you so choose. I've used this method by creating a folder within the root of my Solution (I call it 'Tools' but the name doesn't matter). Within that Tools folder, I add a PowerShell script AND the octo.exe. The PS script fires the Octo.exe which makes a call to my Octopus Server and with the "create release" option, I'm able to automatically deploy to whatever environment AFTER my build finishes within TFS. Make sure to always include those files (right-click in VS and in file properties select 'always copy').
I'm not quite sure why your NuGet packages would not be configured correctly, but that should be remedied first. Your question is trying to ask for two things and it's not clear which is more important to you; NuGet package or the Deployment from CI build. Having said that, I think you need to give more details on why you think your NuGet package is inadequate or not working correctly for your Azure services.
Please note, the site you supplied is using a custom PowerShell script in the form of a step template. It may be best to try the default Azure step within Octopus first before using a customized script. Just a thought.
Read more about the Octo.exe here: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596
So, here is the deal. In web app project settings I configured a deployment package which includes all content files along with IIS settings for the site & app pool. Now, when i go to Team Build build config, I use the following arguments to deploy the site.
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=WMSVC
/p:MSDeployServiceUrl=https://<servername>:8172/MsDeploy.axd
/p:AllowUntrustedCertificate=True
/p:DeployIisAppPath="mysite.com"
/p:UserName=<domain>\<user>
/p:Password=<password>
While this actually works, the deployment will fail if "mysite.com" site doesn't exist on the destination server or if the app pool isn't set up correctly (i.e. ASP.NET version mismatch). So i find myself creating this stuff manually before i can deploy anything from Team Build. Is there a way to automate this? Am i missing some kind of argument switch? I guess another way to phrase this question, is why do i have to set all this up when the package includes all of IIS settings and should just deploy.
Thanks for any help/explanation.
EDIT:
I'm not entirely sure if this is true, but i believe i will not be able to do create site/app pool. From my understanding of things, Team Build uses msbuild to talk to msdeploy and that link is very limited in what it can do. So, I may be looking at changing the build workflow template to execute the command line to deploy the package (?).
Check out the TechNet documentation on the iisApp provider at
http://technet.microsoft.com/en-us/library/dd569054(WS.10).aspx. Of the four parameters, these are the ones you'd probably be interested in:
managedRuntimeVersion
skipAppCreation
I have a team foundation server with build server, when I run a build it deploys to a website on that box. However I also want to do the same on Production which is a server on an external network and not part of the same domain.
I thought about looking at TFS Deployer but that just seemed to work within a network, I'm going to test it out as soon as I get a chance but I thought the best idea was to ask here when working with something so critical.
Is it a really bad idea to have a way of easily deploying to production?
Does anyone here deploy to production using whatever method? How do you do it?
Essentially the accepted answer will go to the person who can tell me the best method for achieving a deployment but pointing me in the right direction is sure to get an up vote as long as it's not too obvious.
Depending on the infrastructure you have available to you you can use wix to create msi's and use SMS configuration manager to deploy them to a target collection. This is the direction that we are moving to but have not reached yet. We also integrated wix into our build process to create the MSI artifacts. The reason we wanted to go down this path was because we are using CruiseControl.net as our continuous integration server and we have a nant script that we use to perform both the build process and the deployment process. They are both separate targets in the nant file, but what we wanted was a consistent model of deployment to all environments including production.
What are are doing currently is we are manually moving zips (which are artifacts of our current build process) to production. When the zips are unpackaged in the production environment we have to remove all the web.config, app.config etc from the zips and if we have new entries in the configs they are made manually.
Found msdeploy http://blogs.iis.net/msdeploy/archive/2008/01/22/welcome-to-the-web-deployment-team-blog.aspx