Apologies if this is basic, but I seem to just be missing something.
I have a single solution with multiple class libraries and 2 MVC 4 web applications.
I've had one of those web projects for ages, and a Team City CI build that generates an artifact that I then deploy via Octopus Deploy. This works great.
I can't figure out the simplest way to either generate a 2nd artifact for the 2nd web project (same tc build, or a different one, I don't care).
End result: I want both web projects to be deployed to the same environments (IIS 7), with the 2nd site simply on a different port. I don't need TC to do anything special, just nuget restore, build, then generate the artifact.
If you always want to deploy both web applications at the same time. E.g they have some shared code libraries, then it's best to setup the deployments as multiple build configurations in a single project.
E.g
Build project A
Build project B
Deploy project A
Deploy project B
If you want to build and deploy the applications separately, then setup the two separate projects. This will allow you to have different build triggers, deploy schedules for both applications.
E.g.
Project A
Build
Deploy
Project B
Build
Deploy
In addition to this, you will need to have a nuget package for each web application. That means you need to run Octopack for each web app and have a nuspec file. Each project will need to generate its own nuget package artifact. In Octopus deploy, you need to either setup a single project with 2 steps or have 2 projects.
Related
I am using Azure DevOps + Test Plans and I am trying to figure out how to refer to a pipeline in another project (which is responsible for the production builds, but kept separate from the component pipelines on one project)
However, when I try to select the project it is grayed out. I have project admin rights on both projects.
I have 5 projects in 1 solution with 3 applications and 2 libraries. How do I publish each application?
show image
Note: I don't know the ASP.NET. I just want to upload this project to server.
You can write a build script to publish EE.UI, EE.API and EE.Admin all together but for different addresses using dotnet publish. You will need publish profiles that you can create using Visual-Studio.
The other two projects are only libraries. When they are referenced, they will automatically be compiled with the executable projects.
I've been setting up Continuous integration, and deployment in Team Foundation Server Online. When VSTSreleases the build to the DEV server (with the IIS Deployment template) the wrong project is being released.
The image below shows the project structure in my solution (asp.net core). I just need to deploy the WebApp.Web.MVC project which has dependencies on several other projects in the solution. Instead, VSTS deploys the WebApp.Application.Shared project.
I've tried moving the MVC project to the top of the list by putting an A in front of it. Also tried adding a parameter in the VSTS build definition with name 'Project' and value 'WebApp.Web.Mvc'. No results though.
So I've managed to solve this problem by doing the following:
I added an additional step in the build process, first the entire solution is build, and then the second step is to build only the MVC project by referring to the mvc.csproj. Now, only the MVC project and its dependencies are being released to the IIS website.
Entire solution
Only MVC project
I come from a Continuous Integration and Continuous Delivery (CI-CD) implementation project background for java web applications. Now i am working for a .NET based project. Microsoft technologies is completely new to me. It is using the MsBuild for the build process via Jenkins. I am learning MsBuild at this time. The more i read, the more confused i am with the Microsoft way of doing this.
I noticed that the msbuild is executed for every environment where the app is going to be deployed using various configuration and profiles based on the environment for the deployment. Below are some msbuild commands for 2 different environments (PIE & TEST)
C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=PIE /m:4 /nr:false src/myapp.sln
C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=TEST /t:Rebuild /m:2 /p:DeployOnBuild=true /p:PublishProfile=TEST src/myapp.sln
C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=STAGE /t:Rebuild /p:DeployOnBuild=true /p:PublishProfile=STAGE /m:2 SprintA/src/myapp.sln
i may be wrong, but i feel that the code being deployed to the two environments (when the code progress from PIE to TEST) is being build for each environment which is not the real code progression concept. IMHO, the build is done once and its progressed to subsequent environments for testing/validation as long as there are no bugs in the code. The various environment specific settings are handled via config files inside the package and the containers (tomcat for a java app) are started with the parameters that reads/parse the confif files.
Is there a way to handle this in .NET? The app is deployed in IIS
UPDATE:
The more i do research reading various docs and blogs, i came across the web publishing method using msbuild for each configuration and the deploy/publish profiles. IS this just the standard way that the mass follows for a .net project's CICD?
Yes, this is something Microsoft realized and is enforced using the new Release System.
Basically you have a "process" (Build) building your code and producing artifacts (ie. website file structure, nuget package, installers, etc) in this process you typically take care of things like applying the version value to your assemblies, minifiying js and css files or anything not related with the any specific environment.
Then you have another "process" (Release) to configure your artifacts based on the environment where they will be deployed (ie. modifying web.config files from your website) and deploy those artifacts to the desired environment without having to build them again. (ie. push nuget package to some pre-production nuget feed, copy you website structure to the server, etc)
How do you implement these two "processes"?. Well, that depends on your preference and tools. If you use Visual Studio Team Services you have these processes clearly defined out of the box by the infrastructure, and a lot of built in task to support them.
I have not worked with Jenkins but as long as you can use msbuild you could have 2 msbuild projects one to build your artifacts from the source code on different branches and another one to deploy to different environments base on some configurations (ei. your PIE & TEST) and of course you could use tools like powershell or MSbuild custom tasks to support more advanced scenarios within your processes.
Here's what I want to do:
Build an existing .csproj that targets "Package"
Publish the package with MSDeploy to an IIS 6 server
This is for a TeamCity build and release that I'm trying to configure in a single step. I could create a custom build file but I'm trying to tackle this without adding any additional configurations to the app.
There are a lot of examples around of MSBuild parameters which can do this publishing via WMSVC - here's a great one - but that's not going to play ball with IIS 6. Are there equivalent params which can be used when there is a dependency on MsDepSvc? Is this even possible or am I left with either a custom build script or a package build followed by a publish build?
You can modify an existing .csproj file to add any additional target needed (it's just an MSBuild file) and publishing to an IIS6 server can be done via different MSDeploy providers (webServer60, metaKey, or contentPath via a share).
While this would be possible to do by adding a Target in the MSBuild of your project, I'd recommend that you split these two activities out into two separate targets. By splitting them into two separate targets you can still call them together msbuild /t:Package;Deploy but you can also call them independently.
This would allow you to create a deployment package and have TeamCity include it as an artifact of the build. You could then download this package from TeamCity and deploy it to any server independently, even if you deployed it automatically. If TeamCity also creates your release builds, you know have your production deployment