I have a solution with multiple projects, 2 of which are the main projects. A .NET WinForms desktop app and an ASP.NET WebApi2.
I have defined a number of publish profiles in Server project, which currently I execute manually. Now, moving to an Azure build pipeline I have a couple of questions:
I create a new pipeline based on the ASP.NET template, which builds all the projects within the solution. Should I leave as is, or should I exclude the client-side projects. If yes, then how can I achieve this?
I'm used to Visual Studio building and publishing just afterwards. In a CI/CD scenario, I assume that the I need to separate the building and publishing/deploying. Is this correct?
It all depends, you may use the same pipeline do build WinForms to create a package/installer. It is all up to you. If you want to exclude you may do it creating configuration
Configuration Manager -> Active Solution Configuration -> New ...
and then you will define what project you want to build. Next you will use this configuration in your build to just compile project you want.
You may pass configuration here.
If you use YAML pipeline instead of classic you may consider using multi stage pipeline. Here you have documentation and here a simple tutorial. If you decide to have one pipeline please check deployment jobs for deploying your app, however this is not necessary.
You you secleted classic pipeline you should go with classic release pipelines.
Related
We are using VSTS for build and release management, and using CI/CD. Typically, our solutions consist of a web application project, and a database project.
Our current release tasks take the application offline (using app_offline.htm), publish the database, then publish the web application. Publishing the database project often results in no changes, as due to CI/CD we are much more frequently updating code on the web app than changing the db schema.
Is there a way to only run the database publish task (using WinRM) when it detects a change in the database project code, in our git repository?
EDIT: This in itself isn't a problem, as typically when the DACPAC gets published, there will be no activity. HOWEVER, I've been requesting that the database is backed up using the /p:BackupDatabaseBeforeChanges=true flag - which seems to back up the database even if there are no changes. This is an issue for large databases.
The simple way is that you can separate web project and database project to two build definitions.
Create a new build definition
Enable Continuous Integration in Triggers tab
Specify Path filter to include database project
Modify Visual Studio Build task, specify /t:[database project name] argument in MSBuild Arguments box to just build database project
The same steps for web project
Create a new related definition
Add artifacts for previous two build definitions and enable Continuous deployment trigger
Add two environments (e.g. database, web)
Open Pre-deployment conditions of an environment (e.g. database)
Enable Artifact filters and select corresponding artifact (e.g. database build artifact), specify build branch (can specify *, it means all branches)
Add tasks to just deploy database in this environment
The same steps for web environment
The answer is - exactly what I want isn't possible.
During build msbuild creates deployment packages for several my web projects (and wcf services) which I want to run from command line (as last step of automated build process) to deploy to several different servers.
The structure of IIS application folders is the same on each one.
My problem is that I cannot find how to configure (override default value of IIS application). It is in .SetParameters.xml, like:
which is not what I want.
I read that it is possible to create parameters.xml in the project and put there something like:
or some say
I'm trying this but it does not change content of .SetParameters.xml
Can you advice what am I missing, or/and alternative way to do this.
Thanks!
If you want to deploy the web application package manually—either by running the .deploy.cmd file or by running MSDeploy.exe from the command line—there's nothing to stop you manually editing the SetParameters.xml file prior to the deployment. However, if you’re working on an enterprise-scale solution, you may need to deploy a web application package as part of a larger, automated build and deployment process. In this scenario, you need the Microsoft Build Engine (MSBuild) to modify the SetParameters.xml file for you. You can do this by using the MSBuild XmlPoke task.
For more information, please refer to: https://www.asp.net/web-forms/overview/deployment/web-deployment-in-the-enterprise/configuring-parameters-for-web-package-deployment
I am new to Jenkins CI tool and I want to know if it is possible to specify what build to use when there are several projects, on different SVN locations, dependent on one another. For example, if I have the web project on SVN location1 and the backend project on SVN location2 and the web depends on the backend and one of the developers modifies something in backend, when the web developer does a commit, there will be a build failure. Is there the possibility to specify that the build from the web part should take into consideration build x from backend and not the newest build?
Thanks in advance.
yes that can be done. in Jenkins check for the Build Triggers options in your project web-settings and on the line Build after other projects are built you can specify the name of projects you want to build automatically after there has been changes made to the base project.
And similarly, in the Post-build Actions, look for Build other projects, where you can specify that if the base project builds successfully, it will automatically trigger a build on children projects.
Hope this helps.
Your example of building a project against a specific version of another project is a little non-standard, but not impossible.
In your case, I would use Jenkins' ability to execute arbitrary scripts to help. The script would take care of getting the correct version of the project that the one I want to build depends on.
Building on your example of a Web and Backend project, here's how I would do things without using a parametrized build:
Add a file to the repository of the Web project that stores the version of the Backend project to use
Configure a job to build the Web project when the source for the backend project changes in SVN.
The project should check out the latest version of the Web project
The first Build Step for the project would be a script (Execute Shell or Execute Windows Batch Command) that does the following:
Gets the version of the Backend to use from the file containing the version info
Either pulls the appropriate version of the Backend from the Backend's repository; or pulls the source of the appropriate version of the Backend's source
(If you pulled the source only for the Backend, the next Build Step should be to build the Backend next)
Build the Web piece
Do any unit tests
I wonder if I could get some feedback from people on how to best approach building of Visual Studio solutions.
My core requirements would be to ensure that any code/tests run against the correct resources, in particular, database schema and sample data.
I've tried various ways to do this with mixed degrees of success. Currently, I …
Create a class library *.Installation.dll, which creates, configures
and populates the database, etc.
Have a class library *.Build.dll
which has an MSBuild task that takes parameters from the csproj file
and passes to the Installation.dll.
These sit within their own solution. Say MyApp.Build.sln. I maintain this separately from my main solution, to prevent file locking issues.
In my main solution, say MyApp.sln …
Then, my test projects invoke the MSBuild task to create test environments for integration testing including database and sample test data.
And my Web/Windows front end projects invoke the MSBuild to create runnable environments for test users/my manual testing
So, I am using MSBuild to create customisable builds/environments for testing/running. Additionally, I can wrap the Installation.dll into a configuration/setup tool to automate the installation for the user when the time comes to install.
Is this too complex a scenario? I'm worried I've over engineered this and overlooked something. It works well, but is bound by a lot of meta programming (eg. the database build code, configuration, build task, etc.) that is not directly involved with tangible, chargeable work.
I have SubVersion and TeamCity. I'd like to enable a CI build ultimately that is invokes on a daily/commit build trigger. Or can I use TeamCity in such a way to avoid rebuilding the database/etc. every build?
Thanks for any insight.
To increase the automated part of our build/release process, I would like to integrate some custom tasks in our visual studio projects. What's the best way to organize such solutions? The main problem is: If I add the project implementing the tasks to the solution, the tasks are cached by the visual studio instance. So a rebuild does not work, because the output assemblies of the task project cannot be overwritten.
I can put the task in a separate solution. Seems to be the best (only?) option, but I don't like to maintain two solutions. This makes continous integration more complicated.
Any hints? How do you manage solutions having project specific custom build tasks?
If the custom build tasks refer to some documents included in the solution, then you can make a custom build rules document, refer it in your solution and specify the custom build name for each document in the properties (this will spare you on writing command, dependencies and everything for each document, if the rule is specified correctly using the macros like $(InputPath), etc.)
If the custom build tasks refer to some operations that are not related to documents in solution, you can have them specified as commands in the post build event of the project in the solution that needs it. Another alternative can be to add a new, dummy project in the solution that will have only this post build event, dependent on all the other projects (so the post build tasks will be called only after all the other projects were built).