I have an ASP.NET MVC solution with the following structure:
Solution.sln
--- Solution/Main.csproj
--- Solution.Services.UnitTest/Solution.Services.UnitTest.csproj
For simplicity in this question, lets say my Main solution is both my website and services. So we have one solution with is the "application".
The UnitTest solution is a simple solution that refers the Main project, but with a lot of unit tests (using NUnit).
I have setup automatic deployment in Azure. Every time I make a commit on develop it updates one web-app, and when I update master, it updates another web-app. I've done this by setting up the integration to my Github repo here inside the Azure portal:
Webapp --> Deployment --> Deployment Options
My question is: how do I run my unit test first?
I don't see any options to add this. I don't see any option if I use the newer Continious Delivery (Preview) either.
I can see there is an option to add performance tests, but thatis not what I need.
So my question is two-fold: How do I add these unit tests inside the Azure web portal / updating my build file? And if this is not possible inside Azure, what is the "norm" on how to solve this (very common, I assume) problem?
You can add a custom KUDU script to the root directory of your solution. At that point you have "complete" control over the build and deploy pipeline in Azure. Every web app has a default script in Azure. If you pull your current KUDU script (assuming your are using dotnet core), you should just need to add a dotnet test command before the dotnet publish command and fail accordingly.
https://github.com/projectkudu/kudu/wiki/Custom-Deployment-Script
If you have looking for a friendlier alternative, then you can use any number of CI/CD tools outside of Azure. VSTS offers several free build minutes every month.
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
I'm doing a web site deployment in azure with bit bucket source.
When I do the deployments I can see always its building the source,
Actually that is not required to me, because it is a Kentico 10 web site (.Net website project).
How do i avoid building while source deployment/ pull the latest from bitbuckt ?
You should stop using continuous integration process in bitbucket and hook your own process to do a xcopy (preferably delta) to target website folder.
Using the OOB tools it is not possible to deploy without a build. So you can do a few things:
FTP
Visual Studio publish
command line copy after a successful build locally.
Another setup could reduce the number of builds you have when deploying but will still build the solution, more branches in Bitbucket.
You could continue to use CI but make sure you hook your environments to proper branches so they only deploy when you perform a merge into that branch.
How do i avoid building while source deployment/ pull the latest from bitbuckt ?
You could check the deployment details under "DEPLOYMENT > Deployment options" as follows:
And you could leverage KUDU and check the auto-generated deploy.cmd file under D:\home\site\deployments\tools\deploy.cmd.
For your requirement, I would recommend you customize your deploy.cmd file, and put .deployment and deploy.cmd files into your Bitbucket repository. For a simple way, you could just download your current deployment script and modify the scripts under the Deployment section, you need to remove the script for building your solution and just leave the script for kudu sync, and you need to modify the value for the -f option from "%DEPLOYMENT_TEMP%" to "%DEPLOYMENT_SOURCE%" when invoking the %KUDU_SYNC_COMMAND%. Details you could follow Custom Deployment Script.
If you want to deploy the full content of your repo with no build or transformation at all, just set SCM_SCRIPT_GENERATOR_ARGS=--basic in the Azure App Settings. This will force the script generator to treat is as a 'basic' site, and won't do any build.
See wiki for more info.
Is there a way to automatically Zip/archive the entire solution after I right click on the project file and click "Publish"?
I've ran into some issue trying to revert to previous versions of my application because I forgot to check everything in after a publish. And someimtes TFS is tricky to get a snapshot of the app at a given date. Having a ZIP archive of each time there was a publish or build would be very beneficial.
If you are building a Web application, your website project should have a tab where you can set the "Package/Publish Web" settings for different build configurations. This should allow you to generate ZIP packages when building.
For the standard 'Debug' build that most developer's use on their machine, you won't want this on, but you might want to configure it for other build configurations.
Some good MSDN reads on the topic are:
ASP.NET Web Application Project Deployment Overview
How to: Create an Automated Build and Deployment Solution with Team Foundation Server Team Build
Common practice is to do that on build server side. Any continuous integration system allows to perform actions on successful build. Not a good practice to increase build time on developer's machine, because it would affect productivity.
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.
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