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.
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 am planning of using Visual Studio TFS server for Continuous Deployment.
I have few projects which are related and when a particular project is updated it might rigger a change in that related project
E.g. Web Project and a Middle Layer API project
Now when I follow CD , how can I ensure that Middle layer API project is deployed before the Web Project is deployed
You have to create only one release to deploy your two related projects.
Choose one of them as the main artifact. Let's say the web project.
At the artifacts page in the release configuration, add your middle layer project as another artifact to the release.
Now that you have your two target projects, setup your release pipeline so that you add the steps to deploy your layer project before your web project.
I'm trying to create web deploy packages through visual studio team services.
Currently, I have created a web deploy publish profile in Visual Studio. I use MSBuild in Visual Studio Team Services to build the solution and create a web deploy package. I then zip the package and save it to a shared location. However, the issue with this approach is that it does not provide me a way have a same build for different environments. Let us say, I created a web deploy package for DEV environment. Then when I have to deploy the build to SIT environment, I would need to build the solution again and create a package. This way I would have different builds for different environments. I would like to have the same build get promoted to different environment for better traceability and maintenance.
One way I feel I can achieve this is to have a separate build definition for just building the application and save the DLLs to a shared location. I can then have a separate build definition which takes the build from shared location and create a web deploy package from the build. How can I achieve that on VSTS?
Other way possible is creating a label when any deployment happens one environment, say Dev environment. To do the deployment in SIT I can use the source code with same label and then use MSBuild to create a web deployment package. Is there any way to achieve this through VSTS with/ without creating a separate build definition of each environment?
Any other suggestions than above?
You can use VSTS Release Management to deploy your deployment package to different environment and use "Tokenizer" task in Release Management Utility tasks to update the config file in the package base on the variable for different environment configurations.
And you can also try with Web Deploy Parameterization.
Is there a way for a Web Deploy operation to Azure App Services to delete a specific folder on the server before the deployment starts?
I need certain files to be removed on the server when they are removed on the solution and deployment leaves those files intact on the server which is causing issues.
Is there any way to add this to the publishing profile as a pre-publish action?
Just to add more context, this is an ASP.NET project using C#. Sitecore is the CMS.
i have tried to find something specific to the SiteCore and not msbuild BeforePublish target, but it looks like you have two options here:
1) Use msbuild BeforePublish target
2) Use Visual Studio Team Services build Continuous Integration - it will need some additional manual tasks, but nothing serious and it is much more visual than msbuild.
I would highly recommend to try the second option - here, you can specify build steps like Take sources => build => execute some command (here is your place to put something for deleting the files) => publish.
I'm not sure if Visual Studio 2010 already does this or not with respect to how it packages Azure deployments, but I have a Visual Studio solution which contains 5 projects:
The Azure Service Project
The project for my web role
2 class library projects which
contain the DAL and BLL that my
roles use
And one MS Test project used for
unit and integration testing across
all of these projects
My deployment package right now is roughly 100 mbs, and takes a while to upload. I have some other things I can do to make it smaller, but what I want to know is if there's a way I can make sure that the MS Test project isn't being packaged alongside everything else given that it has the largest footprint. Any suggestions, or is this not actually a problem?
As long as there are no references from your web role, the DAL or BAL projects to the test project, then it shouldn't be included in the package.
If you're worried about it I would first of all double check all of the references in the web role, DAL and BLL projects to make sure that you're not accidentally referencing the test project.
As long as that is OK, I'd then do a publish of the project to disk and then have a poke around in the \bin directory if the cloud project to see what's actually using up all of that space.
Just as stated before is you do not have any references to your test project in your web role you should not worry for having it deployed alongside the rest of your code.
Another thing I would recommed is to just precompile your web site and
add it as another site in your file using a host header for it.
The advantage of that is that you can create a msbuild task to precompiled your site and just upload it.
Also I reposted about a solution for putting your view files in azure storage which will allow you to modify appearance without going thru the republish process.
http://blogs.artinsoft.net/mrojas/archive/2011/05/01/windows-azure-and-websites-in-a-flux.aspx