I am currently using Visual Studio Team Services (was VS Online) to version control my projects. When I want to deploy my projects to my VPS I use the Visual Studio Publish that stores the files on my hard drive and then I use an FTP client to send the files to my VPS.
But now I am viewing the build and release functions in Visual Studio Team Services. But I don't completely understand it all.
Questions:
What is the purpose of the build?
I have created a new standard build definition using the Visual Studio template and used the Host agent pool.
When I run the build I can see that it creates a new version using the last commit as reference. But what has it done in the backend on the host agent?
And where are the files stored of this new created build? In the log I see Copy Files to: $(build.artifactstagingdirectory) but where is this?
What is the purpose of the release?
I have created a new release plan using the empty template because I don't have Azure, I use another company where I have a VPS running.
I then added 3 environments called Development, Staging and Production.
All of them using the Host agent, but I think here I need to adjust this because if I understand it I now can assign my VPS to my Production environment or not?
Does someone has done this using Visual Studio Team Services and a VPS that runs on Windows Server 2012?
Are there videos or docs available about this because its quite confusing what the correct steps are in deploying versions of web projects.
In general, "Build" focus on integrating and building your code changes and run some basic unit tests. And "Release" is used to deploy the output of "Build" to your environments so that you can run some future tests/verification and final deploy the output to a production environment for your customers to use. See this link for reference: What is the difference between build and release engineering, DevOps and site reliability engineering?
When you start a build without any source version specified, it will get the latest version of the code and then build the code. All the files are placed in the working folder of the build agent during the build process. $(build.artifactstagingdirectory) is a predefined variable that point to a path in the build agent work folder. We usually copy the build output to this path so that we can access to output easily in the following tasks. For example, use "Publish Artifact" task to publish the output files in $(build.artifactstagingdirectory) folder to the server or a file share, and then the team members can get this build from server or file share.
In the release, you can link a release to the build definition. When the release starts, it will get the latest artifacts of the build and deploy to your environment.
The agent is a machine used to execute the tasks in build/release definition. Hosted agent is managed by Azure and you can also deploy your own build agent. So you don't need to change the agent settings for "Production" environment if your VPS can be accessed by the Hosted agent. Since you are using FTP to upload files to your VPS previously, you can still use this method to publish the files by adding a FTP Uploader task in release definition.
For more information, refer to Build and Release Management for details.
Related
Can Visual Studio be configured to Publish (deploy) and Push (to GIT) simultaneously?
I have Visual Studio configured to "Publish" "only files needed to run this application" to a folder on a remote server which IIS is pointing to. When I make local changes, I can publish remotely easily.
I've also configured GIT for the project. The publish information is in the repo so that anyone can pull the project, make changes, and Publish. My general practice is to Pull, work, Push to GIT, then Publish the site--all using VS.
What is the best way to synchronize these actions? I don't want anyone to publish the app and forget to push to GIT at the same time.
I've worked with dev/production servers using typical web layouts before (i.e. push to git repo that IS the location of production files), but in this case that doesn't work because of the minimalist file structure of a "Published" site. I'd have to coordinate the exclude files in GIT with the files "not used" for publishing.
Visual Studio 2017, IIS 10.0
EDIT:
The GIT server as well as the project are hosted internally (albeit on different servers). Storing the code locally is a requirement, I cannot upload to TFS (so, so unfortunately).
Your requirement can be achieved in TFS/VSTS easily.
First, TFS/VSTS supports GIT version control, you can use it version control your project. You can refer to the following link for more details:
https://learn.microsoft.com/en-us/vsts/git/gitquickstart?view=vsts&tabs=visual-studio
Also, TFS/VSTS supports continuous integration and continuous deployment. A continuous integration trigger on a build definition indicates that the system should automatically queue a new build whenever a code change is committed. You can make the trigger more general or more specific, and also schedule your build (for example, on a nightly basis). You could also enable the Continuous deployment trigger, which will create release every time a new build is available.
https://learn.microsoft.com/en-us/vsts/build-release/actions/ci-cd-part-1?view=vsts
Background: I am doing a POC for CI using Jenkins and MSBuild. I have installed Jenkins, MSBuild plugin and other required components on my machine and configured as well. But I don't have IIS configured on my development machine.
I want build the ASP.NET website and output the published code in a folder "c:\precompiledweb" using MSBuild script. I have
Can someone help me with MSBUild Script.
Make sure you read the prerequisites for functionality.
https://msdn.microsoft.com/en-us/library/1y1404zt.aspx
Walkthrough: Deploying a Web Site Project by Using the Publish Web Site Tool
Prerequisites
In order to complete this walkthrough, you will need the following:
Visual Studio.
*This walkthrough assumes that you selected the Web Development collection of settings when you started Visual Studio the first time. For more information, see How to: Select Web Development Environment Settings.
Access to Microsoft Internet Information Services (IIS) so that you can test the result of publishing a Web site project. In this walkthrough, it is assumed that you have IIS running on your own computer. Alternatively, you can use any instance of IIS for which you have permission to create a virtual directory.*
You need access to some IIS server.
On the flip side....you need to keep this general rule in mind. Jenkins is simply a fancy wrapper for command line calls.
So test the below (article) on your machine without IIS. If you can get the command line to work (outside of jenkins), most likely you can get it working (inside jenkins)
http://www.asp.net/mvc/overview/deployment/visual-studio-web-deployment/command-line-deployment
Configure Source Code Management section, i.e. for TFS:
Add build step "Execute Windows batch command"
Insert msbuild invocation to your solution, i.e.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
"%WORKSPACE%\{solution_name}.sln"
You can add some optional parameters.
After build you can add another script invocation (batch, powershell, whatever) for copy project output to specific folder, but I would prefer another way: publish to IIS and run application immediately.
in Visual Studio create publish profile with WebDeploy target (help)
enable Web Deploy in IIS on test machine (help - when componentes are already installed go to "USING THE IIS MANAGER TO CONFIGURE WEB DEPLOY FOR A NON-ADMINISTRATOR" section)
add publish parameters to jenkins job from step 2, i.e.:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
"%WORKSPACE%\ {solution_name}.sln"
/P:DeployOnBuild=true
/p:PublishProfile="{publish_profile_filename}.pubxml"
/p:Configuration=Release
/p:Platform="Any CPU"
/p:Password={Password_for_publish_profile_same_as_used_in_VS}
And now you have jenkins click-once job for build and publish solution to test server. Add Source Code change trigger and you have basic CI.
What are the options for deploying a web-application that is built daily using Visual Studio Online (and hosted controller) and its new build definitions to an on-premises IIS behind a firewall?
If opening up the firewall, would it be possible to add some kind of WebDeploy-build step to the Visual Studio Online build? Haven't seen any WebDeploy build steps for now though...
...or could we write a PowerShell script running daily on the IIS-server that fetches the output of the daily build from Visual Studio Online? If that's possible, how can those files be accessed?
...or could something like OctopusDeploy help out here?
would like to refrain from having to set up an on-premises build controller.
VSO Agents are lightweight and easy to setup if you have a server available. Octopus Deploy integrates nicely most on premise scenarios.
That said, if you still want to keep hosted builds, Octopus would still work.
Create a VSO build definition and include OctoPack.
Pick a hosted Nuget Server, presumably with a private repo subscription. A couple of options are MyGet and Artifactory.
In "MSBuild Arguements" include the parameters.
/p:RunOctoPack=true
/p:OctoPackPublishPackageToHttp=http://nugetrepoofyourchoice.com/nuget/packages
/p:OctoPackPublishApiKey=$(NugetAPI)
/p:OctoPackPackageVersion=$(Build.BuildNumber)
"NugetAPI" is actually a user defined variable (name of your choice) that references a Secret build variable. You will get this API Key from your Nuget Repo vendor.
On premise, in your Octopus installation, you would define your hosted Nuget feed as an external feed.
In your deployment project, it would pull the Nuget package from your hosted repo.
VSO pushes to hosted Nuget feed and Octopus pulls from the hosted Nuget feed.
Octopus deploy would work for this in a couple of ways.
1) Install a tentacle on the IIS server (either polling or listening will work depending on where you install octopus manager)
or
2) Install the main octopus deploy on a machine that has WebDeploy access to your IIS server, and use the custom library MS Deploy script
Getting the package to the main octopus deploy machine could be a bit tricky. Easiest way would be setting up a MyGet server and have the octopus server check it periodically, that way you don't need to open up firewalls to the public.
These feature are coming for VSO and were announced at Build. You will be able to deploy on-premises without needing to open a firewall port using agents.
While this is still in the works you can use Release Management for Visual Studio 2015 to pull the bits from VSO and deploy locally.
Currently we deploy compiled ASP.Net applications by publishing the web site locally and emailing a zip file to the system administrator with a (usually) lengthy set of instructions for deployment. This is because the first time we deployed an ASP.Net application to a customer the dev and test IIS instance were the same, and we were unable to deploy the site twice to the same machine. This set the tone for deployment on all subsequent projects.
I am now evaluating our deployment methods and am looking specifically at the built in deployment tools; specifically I'm looking at custom installation tasks and using as much of the standard installer functionality as I can (mostly the user interface).
Secondly, I'm looking at merging deployments and automatic updates.
How do you go about deploying sofware in your organisation? What tools do you use, and what problems do you come across most frequently?
We have dedicated DEV, TEST, STAGE, and PRODUCTION servers.
We also have a dedicated build machine which runs Cruise Control.
Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks.
To deploy to development, the code is first retrieved from SVN and built, then the "Precompiled Web" folder is copied to the development web site, and the web service project is copied to the development application server. Cruise Control is also configured to "tag" the source code before the build starts so we can reproduce the build at a later time, or branch from the tag if we need to do a hot fix.
To deploy to QA, the files are copied from the development machines to the QA machines.
Likewise, to deploy to Stage the files are copied from the QA machines to the Stage machines.
Finally, to deploy to production, the files are again copied from the Stage machines to the Production machines.
To configure each environment, we have a custom tool which is part of each environment's Cruise Control task that modifies connection strings, "debug=true|false", "customErrors=Off|RemoteOnly", and other environment-specific settings.
So each environment can be deployed with a button push from the Cruise Control dashboard.
One caveat is that we currently have the production database password configured in the Cruise Control config file...it would be nice move it elsewhere!
Lastly, let me add that even though our production machines are in a dedicated hosting facility, the servers are accessible from our Cruise Control machine, which makes it very easy to do a production deployment. The only manual step is to encrypt the web.config files and remove the "AppOffline.html" file that Cruise Control puts up.
Let me know if this helps, or if you have any questions.
Thanks!
A couple things that I have done is the following:
1) Use a Web Deployment Project in order to compile and clean the build as well as handing web.config section replacement if the config changes between environments.
2) Use NAnt to do all of the building, archiving, and copying in a repetitive manner.
The Web Deployment Project ends up creating a MSBuild file which can be used in place of NAnt; however, I came from a Java background and used Ant all of the time so NAnt is my preference in .Net. If you add in the NAnt Contrib tasks, you will be able to deploy not only the files but also handle items such as your source control (incase it is not part of the default tasks) and Sql Script Execution for changes.
Currently I use both of the options together. I have my NAnt build file call the Web Deployment Project through MSBuild. With the configuration manager setup for each environment, it allows me to manage the web.config section replacements automatically and still have fairly decent control over my copying and archiving of a release.
Hope this helps.
We use web deployment projects, and the VS 2008 projects to create an .msi from the output of the webdeployment & other projects. A normal windows app called 'setup' is used to do a lot of the db creation and preliminary stuff, rather than trying to customise the setup projects with custom steps. It is a lot easier to do this yourself than trying to customise the MS code. This windows app then calls the correct .msi files that the user needs.
Team foundation build runs every evening to rebuild the solution and copy everything to a 'Release CD' directory which anyone can access and do testing on the latest 'release'.
To be honest TFS build is a bit overboard for a small team like ours, and I only use it because its what I am used to.
In a previous company we used this http://www.finalbuilder.com/ and I can recommend it for ease of use and for the amount of software supported.
1) Build project with MSBUILD
2) FTP files to Production Environment
3) Copy / Paste manually to each web server
For intranet sites, we use CruiseControl in conjunction with SVN to have the site rebuilt automagically.
Theoretically you could extend this model over a VPN if you could map a drive remotely to a client's intranet. Or a more quick and dirty solution might be to use a tool like SyncBack to sync the remote folder containing the compiled DLLs for the site.
Deploy Web Applications Using the Copy Web Tool
Text from Microsoft Training Kit Book Web Based Development
Web Setup Projects are useful if you are providing a Web application to many users (for example, allowing people to download the application from the Web and install it). If you are responsible for updating a specific Web site for your organization, it’s impractical to log on to the Web server and install a Windows Installer package each time you make an update. For internal applications, you can edit the Web application directly on the Web server. However, changes you make are immediately implemented in your production Web application, and this includes any bugs that might be there. To enable yourself to test a Web application, you can edit a local copy of the Web application on your computer and publish changes to the production Web server using the Copy Web tool. You can also use the Copy Web tool to publish changes from a staging server to a production Web server, or between any two Web servers. The Copy Web tool can copy individual files or an entire Web site to or from a source Web site and a remote Web site. You can also choose to synchronize files, which involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited. The Copy Web tool cannot merge changes within a single file; only complete files can be copied.
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.