I am working as a BizTalk integration developer.
Every time I do build and deploy. It's not a problem for a small project, but it's for a huge BizTalk project .
The question is, is it enough to deploy only and no need to build first and then deploy so that the project works correctly and the new changes are applied in the BizTalk Server?
You always need to build, before deploying. The only exception might be non-BizTalk or non-.NET files, but only if those files are not retrieved from the bin folder but somewhere else during deployment or creation of the deployment package.
Related
I have a .NET solution that contains several projects. I want to set up a deployment pipeline in Azure DevOps but I'm not sure how to do this. I want to have 1 pipeline that deploys the following projects:
Main web app -> needs to go to Azure Web Apps
Portal web app -> also needs to go to Azure Web Apps
Database -> needs to be deployed to SQL Azure Database
How do I set this up? I selected the default 'Azure App Service Deploy' template, but in the deployment task I cannot select which project I want to deploy. The package refers to $(build.artifactstagingdirectory)/**/*.zip, but this is a zip file that contains the artifacts for both my web projects (and the database DACPAC is missing here).
that's many questions in one, but I'd generally separate build\release pipelines for each application (that way you have more control) and you dont have the problem of how to select proper zip file. I'm pretty sure you cant even select a part of zip file (since you now have a single zip file with several solutions), so your approach is not going to work.
as for how to set this up: your build should build 1 project exactly and pack\upload it. and then your release will target that artifact and everything will work just fine.
First things first. Copy the build artefacts into 3 different packages. Say,
Artefacts1: For Web Apps
Artefacts2: For Portal Apps
Artefacts3: For DACPAC files
In this case you will have 3 copy files task copying and 3 publish build artefacts task to publish it to Azure DevOps. In the release pipeline, add 3 agent jobs to perform
Deploy to Web App
Deploy to Portal App
Database DACPAC Deploy
You can refer this to have similar pipeline.
I have done a fair amount of research for publishing and deploying web apps with VSTS and so far I have found the following:
1.Use .pubxml files and pass the DeployOnBuild = True to MSBuildArguments
2.Copy and publish Artifacts and create a separate release definition.
We are currently using the first method, but found that the build can be marked as successful but the publish fails (in our case it was a bad transform)
So we decided to look into separating the publish step and to create a release for our changes.
The issue I am running into is that the copy files and publish artifacts step only copies DLLs and our .js and .html/.css changes don't seem to make it to the UI. As a work around I added these params to the Copy Files method but it is taking a long time to publish. (There are no issues with the release definition)
**\*
!$tf\**
**\!$tf\**
**\!Debug\**
**\*!pdb
All the guides online for using the Publish Artifacts and creating a separate release definition seem to say the same thing, and only push Dlls from the bin folder to the IIS server.
Here is my build definition:
So my question is, why aren't UI changes being deployed to the website when the release completes if this isnt an issue anywhere else?
No, not really. We usually not only publish DLLs and our .js and .html/.css as build artifacts, but for the whole web app.
The Visual Studio Build task usually with the MSBuild Arguments as (if you use ASP.NET build template, it's the default setting):
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
In this way, the web app (published files) will be copyed to $(build.artifactstagingdirectory) directly. So you don’t need the Copy Files task.
If you need to deploy all files, you can use ** in Copy Files task.
Then when you deploy the app to IIS server in release definition, the whole web app in build artifacts will be downloaded.
I've been struggling while trying to create an automated TFS 2010 team build that uses MSDeploy to deploy the website to one of our local boxes. Aside from not being able to find good documentation, a large part of the problem is that the site uses a native C++ dll. I've managed to get things almost working now and the site will deploy during the build BUT the native dll is typically in use and prevents the deployment if the site has been accessed since the last restart. I would like to have the build force an application pool recycle or restart the site/application just prior to deploying the files to the remote server. I can use the following at the command prompt to achieve this manually:
msdeploy -verb:sync -source:recycleApp -dest:recycleApp="Default Web Site/Application",computerName="MyServer"
How do I hook this into the build process so that it occurs before the publishing pipeline tries to copy files to the server?
You could use the InvokeProcess activity in your workflow. You can then invoke a batch script that would contain your command line above.
You can drag the activity and insert it as the step before publishing (assuming you are using the workflow designer).
If you need the script to run as another user there are plenty of helpful suggestions here and in the linked blog.
I already owe SO and Ewald for getting our TFS build up and running.
I know you can copy a Website intact to the server and have it run normally (security and compilation time aside).
What about the projects that are in the solution? [whose dll's are copied to the bin when built]. Is there a way to copy the projects' code files to the server as well?
My goal is to be able to debug [by modifying code in the project if needed] directly on the server without having to install an IDE [or keep building on dev machine and copying over dlls]. I can debug/modify the website files, but not the projects.
EDIT: to clarify, not just debug, but be able to edit.
So long as you upload both the DLLs and the PDBs, you should be able to debug successfully without the raw projects on the server. It can be augmented if you have open the matching project / solutions locally. There really isn't a requirement to upload solution, project, or raw code files to the server to debug effectively, remotely. It should be noted that breakig while debugging will hang the app domain on the target application, and as such, should be done with caution in a multiuser environment.
You do not need the project files in order to debug files.
You should read about remote debugging.
Update:
What you want to do sounds very dangerous in a production environment. If you want to develop, develop locally.
Regardless - project and solution files are organizational tools in visual studio as well as build files for the MSBuild build tool. If you don't have either visual studio or MSBuild installed on the server, there is little point in having the project and solution files on it.
Why do you need to develop on a production machine?
what is the preferred method of deploying a web project? Just copy the dll's after compiling in release mode and registering them? or using NSIS to build an installer or the MS set up project.
I usually use a Web Deployment Project per WebSite or WebApplication, it allows me to manage build configurations, merging, and define pre-post build MSBuild tasks.
You can also take a look to the Microsoft Web Application Installer, it will be really nice, but it still in beta stage, however you can try it...
This depends greatly on where your webapp is going and the experience you wish to provide.
If you deploy to a web host its best to use xcopy deploy and documentation. If you have a real end system its simpler to create an installer to do all the leg work for your customers and maybe save your self some documentation work.
I would recommend investing in setting up a continuous integration process (CruiseControl.Net or TeamCity etc...) As you are probably not only going to deploy it to your customer only once.
Having an automatic deploy at the push of a button is a Godsend. If you invest a few days you can have automatic deploy to a dev-environment every time someone checks in code (and it compiles and all tests pass), set up daily deploys to a test environment and have a button to automatically deploy it to a staging environment whenever you want.
Andreas, I am in the process of getting CC.Net. In the meanwhile, I am using the Web Deployment Project. Using this and going through the set up, it creates a 'release' folder with a bin folder conntaining dll's and also the aspx in the parent folder.
I assume I can now create an MSI file using the 'release' folder or do i need to do something different to create an MSI which i can run on the client server