I have a web application created with ASP.Net WebForms and I would like to know some alternatives to automatize the builds and releases in live version without manual steps (as much as possible):
merge from test branch to main branch (TFS on-promise)
assembly info update (increase version number)
package creation
copy and paste files to live server
update the physical path of web site in IIS
notification emails with result
Related
I have a Visual Studio solution which has various class libraries and several ASP.NET website projects. The website projects reference the class library projects, so for ease of working they need to be in the same solution.
The whole solution is version controlled through Visual Studio Team Services (now Azure DevOps).
When the solution is committed to VSTS, the solution is automatically built by VSTS.
I also want to use continuous integration and deploy the website projects in the solution to various web servers via FTP (FTP is the only option for this, MSDeploy etc is not available). The releases will be triggered by the build on commit.
The problem is that I need to publish the actual website files via FTP during a release triggered by the build, but the build artifact only contains .zip files.
For example, if the solution has a website project called 'MyWebsite' the build artifact has a zip called Mywebsite.zip, but no files are accessible. As such, I can deploy a zip file to the web server, but not the actual website files.
How can I deploy these files?
Furthermore, I don't want to deploy all of the files in the website project. I want to deploy a release version (similar to what is published using Visual Studio 2017's Publish tool), which the zip file seems to contain.
VSTS/Azure Dev Ops has Tasks built in to Extract Files and FTP Upload. The release pipeline also has a variables which you can access via release tasks and powershell. $(System.DefaultWorkingDirectory) is where artifacts(built code) are downloaded to. An Agent Job with two tasks should be able to accomplish what you are looking for.
Tasks
Details
Azure Dev Ops Release Variables
I have visual studio solution with 2 web projects. The source is in VSTS and the apps are hosted in Azure. I have build and release management setup to automatically deploy to Azure.
So every time I check in something, 2 releases are triggered, one for each web project. Is there any way I can separate the two? The web project should only trigger for a check in on that folder and the api trigger for a check in on that folder?
You just need to change Path filters for specific path of each web project path. More information, you can refer to Build definition triggers.
We are currently trying to integrate deploying our new ASP.NET projects with Octopus and I was wondering if anyone has tried to use Octopus to deploy a classic ASP site?
I know it is possible and I know how to do it in theory, but our problem arises from the fact that the ASP site is HUGE. After the total size of all the videos, images, and pdf's are summed up the site weighs in at just under 3 gigs. So when a change is checked into TeamCity and a NuGet package is created, Octopus will be pushing a 3 gig nuget package to 2 individual load balanced servers.
We can't create a shared directory or cdn for the media files (at least not yet) so can anyone tell me a good way to attack this? Or is Octopus just not a good solution for a large ASP site and Web Deploy would be better? If that is the case, how can a backup solution be implemented for Web Deploy so that any errors can be rolled back?
Thanks for the help on this in advance. We are converting these ASP sites to MVC but that is going to take a while and until that is done we have to find a way to work with them.
You should package the ASP site and the Media Files as 2 separate NuGet packages. This will allow you to update the ASP code and deploy it without having to deploy all the media files (assuming the code changes more often than the media).
Implementation Details
Setup TeamCity to package the ASP site and the Media files as separately published NuGet packages.
In Octopus Deploy add each of the 2 NuGet Packages as deployment steps for a single project
When you create a new Release in Octopus select the newest package version for the ASP code and the previously released package version for the media files.
When you deploy the release you can check a box to skip the deployment of the media files
Tips
Use the Octopus variable "OctopusWebSiteName" to specify that your media files package should be deployed in a sub-directory of your ASP site. (Like "Default Web Site/Media") The variable can be scoped to a specific package so that it only applies when deploying that package.
Do you really need to push all the content every time - cant you just push the changes?
I have an ASP.NET MVC 3 Website in C# with
ASP.NET MVC 3 Internet Project
Domain Project (Class Library)
Unit Testing Project
SQL Server 2008 R2 Database
Source Control on Mercurial
What is the easiest way to do a 12:00AM automated nightly build and deployment of the site so that everyday I could go to dev.mycompany.com and would see a live updated version of my Dev version?
I was thinking of using Jenkins to do all of the building.
I help maintain a system much like this -- in Jenkins. Obviously the details will vary based on your project structure, but here's roughly what our Jenkins job does:
Pull code (we use Git but there's a Mercurial plugin for Jenkins as well)
Execute any SQL schema changes against our testing DBs from an idempotent script (we use an Ant script which pre-dates our use of Hudson/Jenkins)
Run msbuild (another Jenkins plugin)
Build file is our .sln (or you can use a web .csproj -- the arguments are slightly different)
Command line arguments:
/p:Configuration=Dev /p:Platform="Any CPU" /p:DeployOnBuild=true /p:DeployTarget=Package /p:DeployIisAppPath="dev.mycompany.com/" /v:m
This builds a .zip file, a .cmd file, and some .xml files, which contain everything you need to deploy updates to your site
Kick off two other "msdeploy" Jenkins jobs, one on each .NET web server
Each .NET web server is also a Jenkins slave
We have two servers in testing, balanced via NLB
Each "msdeploy" job copies the .zip/.cmd/.xml files from the build server to a temporary location on the web server and then runs the .cmd file
The .cmd file executes msdeploy, which pushes everything you need out to your dev web server
We have a separate job that runs our NUnit tests, but you could just as easily incorporate your tests into your main job. One of the reasons we build the whole .sln instead of the web .csproj is so we can run our unit tests from the same built code.
If you haven't already, you will need to install ASP.NET MVC3, .NET 4, and msdeploy on the build server, and I believe you'll need most of the same files on your web servers as well.
For scheduling, you can choose "build periodically" or "poll SCM" as your build trigger, and then use cron-like syntax (0 0 * * *) to run daily at midnight.
In our environment we are serving a combination of asp and asp.net pages on Windows 2003 servers running IIS. We use Visual Studio to edit the pages via FrontPage extentions.
We really enjoy the ability to make quick edits and save and the web is updated immediately. Don't worry, we do have a development server where we test all of our changes before moving them to the production server.
We do not want to use the "publish site" option if at all possible.
I have been using GIT for some android (eclipse) projects lately and I'm really enjoying it, so now I would like to use GIT for our web site as well if at all possible.
I've have GitExtentions installed, along with the VS plugin and I have tried Git Source Control Provider.
Keeping with the distributed VC mindset, I'd like to have a repo on my (and each of the developers) PC and commit as necessary.
The problem is, since we are editing via http/frontpage (master mode) the files are not stored locally.
I am wondering if anyone else in this type of environment has implemented a successful GIT workflow.
Thank you,
My solution isn't necessarily ideal for your situation, given you dont want the extra step of publishing...
I have the files locally in my git repo, and then I manually (via script) push them to the web location.
So I traded the ease of editing deployed files, for the awesomeness that is GIT. For me, I came out like a bandit in that trade.