Using TFS 2010
The solution I am working with is approximately 34 projects. I have gotten my build definition to copy the build output to a separate location. of those 34 only 3 are actually web type projects. This works fine and gives me compiled code.
My issue is that once the build is deployed to that location how to configure the build definition to update the appropriate IIS website/ settings.
I looked at this location already but this seems quite error prone: http://vishaljoshi.blogspot.ca/2010/11/team-build-web-deployment-web-deploy-vs.html
I considered creating a separate .msbuild for each of my csproj files that need to be setup and have it run on Post build. My suspicion though is that this will run on the build server itself and also how would I get for example the path to even update IIS with.
Anyone have any suggestions or tips to make this moderately better?
nutshell: after deploying a different location than build server how do you automate IIS processes to pickup new build.
tyvm
MacM
You should use a deployment automation tool rather than the build tool to tackle this problem, especially if you'll be deploying to several different environments. Any deployment tool with decent IIS support will be setup to update configuration on a per-environment basis. It's the most normal IIS scenario in the world.
I think MS is including the InRelease tech in the new VS, and there are a number of other good solutions for deployment as well including Octopus Deploy, and IBM UrbanCode Deploy. .
Related
I tried searching for deployment methods but the results I was seeing are way to general and meaningless to be useful. Maybe there are some keywords I am missing to find what I am searching for?
I have an .NET Core application and need to push it out to many computers throughout the organization. I also need to be able to push out updates to the application periodically.
Its my understanding that this can be done through Azure but I need to know of any locally contained options that don't rely on internet connections but would work within our local network.
What could I search for to pull up lists of products and/or solutions to achieve something like this?
You can use tools like Teamcity, Jenkins or Octopus. Once installed, it runs on localhost and the build definition can be created to execute periodically. Also, you will be able to add your changes incrementally while planning for new builds.
For TeamCity I recommend the following link -
deploying .NET Core app on TeamCity
For Jenkins and Octopus I came across following -
deployment using Jenkins
deployment using Octopus and Jenkins
We have some ASP.NET web application which used in 2 ways:
enterprise solution (msi-like installer)
cloud solution (use same installer)
Currently we use home-grown installer, but consider if we can replace it with something more convenient and suitable for CI/CD development cycle.
What technologies/products can be used? Currently I think about webdeploy, but not sure how it can be applied for enterprise setup...
This is quite a broad question, but I think it deserves an answer.
1. (partially) Open source solution
One way to configure CI cycle is to use Jenkins along with MS deployment functionality. This article shows how to quickly set up a job to integrate Jenkins with msdeploy tool.
Basically it configures a job to perform the deployment using Powershell:
msdeploy.exe -allowUntrusted=true -verb:sync -source:contentpath='D:\WS\ExampleProject' -dest:contentpath=F:\webfolder,computerName=exampleproject.example.com,Username='yourdomain\username',Password='password' -skip:objectName=dirPath,absolutePath="config" -skip:objectName=filePath,absolutePath="web.config"
It also tells that the executing user should be an administrator on target server, but this can be circumvented through proper configuration of Web Deployment Handler as indicated in this article.
One intermediary step that can be done before Jenkins integration (which I recommend) is to configure Web deployment. This allows to quickly check that deployment can be performed onto target server IIS using Visual Studio and any configured user that is allowed to deploy. It also allows to quickly see the difference between current code base (web pages, JS files, binaries) and target server deployed package.
2. Visual Studio 2017 DevOps solution
Microsoft recently released VS 2017 which contains a great support for DevOps which handles most the issues related to CI/CD. I cannot find a reference, but I remember that this feature is available for Enterprise version only. Also, the good news is that it is not tightened to Microsoft technologies.
A presentation related to the subject can be found here.
I think WebDeploy can be used without significant problems. From my experience with it:
backup limitation: can be done only at Web Site level, not Web application level
deployment time: is quite small - actual files copy + Web site backup (if configured) + application pool recycle.
Recently I saw a vendor offering customers who wanted on-premises deployments the same Docker image that they use for cloud deployments. Seemed like a good, clean, solution.
Another option is nuget packages - host your own repository. Then deploy with a tool like Octopus Deploy. I'm not terribly familiar with it, but both solutions look to be easy after an initial hump in setup.
I've been doing some reading http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html and https://michaelbaylon.wordpress.com/2011/04/13/managing-sql-scripts-and-continuous-integration/ ... etc on automated deployment and continuous integration etc but non of it seems to talk about automated deployment in a classic asp environment and you can't really do proper CI unless you get into automated deployment.
Can MSDeploy deploy a classic asp website? If not ... is it best to just write a build script that copies all the files over to the correct folder and then start up IIS? I've done this using msbuild and the robocopy msbuild extension task. But then how do you handle the different environments (QA, dev, staging, production) there's no web config to put the different connection strings etc ... supposedly msbuild is configuration aware ... but how does that work when there is no web config?
So with all these questions I'm struggling to really move forward with creating a deployment script / module / exe for our classic asp website. Does anyone have any answers / resources / further questions that they can point me in the direction of?
Web Deploy (http://www.iis.net/download/WebDeploy) is the way to go. You just have to customize the deployment script for different environments.
You might find this links helpful:- http://msdn.microsoft.com/en-us/library/ms241740.aspx- "Build" Classic ASP with TFS 2010
MSDEPLOY can deploy anything that can live in IIS. You can create a package from the existing web site, and examine it to see what got packaged. You should be able to use that to determine how to package up your site from sources.
You should even be able to create a Visual Studio project from your sources so that you can use the Web Publishing Pipeline directly. The fact that there is nothing there to compile shouldn't stop you from specifying that your .ASP files are content files.
Checkout using cruisecontrol.net, we use that for our automated deploys along with msbuild and it works great. We are a .Net shop but it's basically the same thing. Cruise Control can run scripts and does handle the web.config / global.asa transformations pretty good. As long as you can script it cruise control could handle it.
Depending on your development environment you might be able to hook it into cruisecontrol. We use TFS and it integrates nicely so when we check items into our different branches (Dev, Main, Stage) it auto deploys the site to the appropriate location.
Deploying to our production environment we use MSbuild to move the code. Since it's in another network location we needed something that could go outside and do any server updates necessary.
http://cruisecontrol.sourceforge.net/
SOX requires that we have a separate group deploy our ASP.NET web to production.
Currently, that group has access to our current code repository in VSS and uses VSS to deploy code that has been checked into VSS.
How are deployments typically done for web applications?
As a developer, I have used the Deploy function in Visual Studio to deploy code to a network share which corresponds to a IS virtual folder, but I don't think we can expect that the deployment group will be purchasing a copy of Visual Studio just to do deployments.
We could check the code into TFS, but what is the minimum software that that group would need to perform the deployment? Would a Team Explorer Client Access suffice?
I am aware that Team System has functionality to automate the building of an application. Do people typically deploy to Production by copying aspx and dlls files from the QA environment to production or do you normally deploy from TFS or even VS directly? It seems to me that the preferred approach would be to deploy from the QA environment, since that is the environment that must have been approved for release or that those files should be checked into TFS and the deployed from TFS, assuming you can deploy from TFS.
What confuses me is whether bin (binary) files that are local to the project-do they go into TFS? Is so, doesn't this create problems for other developers in that only 1 developers-the one with the binary checked - can actually debug because debugging requires write access to the binaries? Does this mean that the binaries shouldn't be checked into TFS? But eventually, if you deploy from TFS, the binaries HAVE to be added to TFS. Are they added as a separate (compiled) application node? If so,m this sounds real ugly. I would assume not. How does one ensure that the binaries match the source code that we mark with a particular version number?
Obviously, I'm clueless. Can someone give me a general idea of how you handle version control and deployments in particular using TFS?
Sounds like you're asking what are best practices for using TFS for deployments. This book from the TFS team should answer most of your questions. The big mindset difference between TFS & VSS is, by default, TFS checkouts do not "lock" a file from being edited by another developer. TFS has a pretty decent merge capability to handle changes to the same file. The TFS books explains this in much more detail and why it is a good thing.
As to the handling of your application binaries, they should normally be generated by the build process and automatically deployed to the target environment (dev, qa, staging). Third-party binaries that your code depends on would be checked-in along with your source code to ensure the build process has all the required assemblies.
As you mentioned, deployments to production should be manually triggered from a qa or staging environment not accessible to developers to comply with SOX rules.
Jaxidian makes a good point about researching Continuous Integration. TFS supports triggering builds on check-in which makes CI possible.
One minimal possibility (i.e. relatively simple and using free software) is using Powershell scripts to compile using MSBuild. To work with your source control, you can use Subversion, which can also be scripted.
I would suggest you do some research into Continuous Integration scenarios to learn more about what you're asking about.
Does Microsoft offer a tool where you can deploy a web application to multiple web servers in a load-balanced environment/web farm?
My team is looking for a tool, preferably from Microsoft, where we can deploy our web application from development environment to production environment automatically.
If I understanding what your asking for your looking for a build server, to my knowledge Microsoft don't offer one, but some to take a look at are Team City, Hudson(requires a plug-in), and CruiseControl.net.
Basically they work by pulling from your source control building your application and running your tests. They all support scripting that will allow you to build then deploy to your servers. This can be set up to run nightly, weekly, etc. you can also set it up to monitor your source control for changes and build anytime it sees a change
The only one I've used is Team City, the install was easy, and depending on how many build agents you need it's free.
If your just looking to build and deploy from VS Another option is creating an NAnt script and running it from VS as an external tool.
For a good over view of Build servers check out this SOF question cruisecontrol.net vs teamcity for continuous integration
The Web Deployment Team blog at Microsoft has some reasonably useful information, and have a deployment tool you could try...
In the last environment we setup we used TeamCity for all our builds and deployments (Which is basically to say we wrote MSBuild scripts and automated them with TeamCity). In short we had the following 5 build configurations:
Continuous Build - Automatically rebuilt our product upon every check-in. Running all the tests. This build did not deploy anywhere
Nightly Build (Dev) - Automatically build and deployed our product to the development web server (no server farm). We build would run the tests, update the development database, shutdown the Dev IIS web site, copy the necessary files to our web server, and restart the site
Test Build - Like our Nightly build only it deployed to our test environment and it wasn't scheduled so it had to be manually started by logging into Team City and pressing a button
Stage Build - Like test only deployed to a web server that was externally visible to our customers sot that they could validate the application. Also, only run on demand.
Production - Created a zip file of our product that the deployment team could install on our production web servers
So I guess what I'm suggesting is that you use TeamCity and then write build scripts in such a way that they'll deploy to your Web Farm. If you want examples I could supply you with the pertinent portions of our build scripts
** One more thing: we check in our web.config files and such for each environment into subversion and then part of the build process is to copy and rename the appropriate config file for the environment. For example, web.prod.config => web.config in our production build
I believe that Sharepoint does this.
File Replication Service ( e.g. DFS Replication ) is a typical and very good choice for doing this.
Your changes are synced between member servers at the file system level.
Sharepoint does this automatically when you deploy a solution package.