There exists a great amount of documentation and samples on how to create build definitions for VSTS and TFS 2015+ for Service Fabric continuous integration and deployment.
What is available in terms of integration with TFS 2013 for deployment of Service Fabric applications?
How do we integrate the build and deployment of on-premises Service Fabric clusters / applications / services with TFS 2013?
Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable distributed applications. It was developed as a Microsoft-internal-only platform for over five years, which shipped publicly as a product in 2015.
The vNext build is also released on 2015 and have many benefit such as simple, deep Customization than XAML build. So most documentation is related to vNext build.
According to the build and release steps in documentation you provided above,it's general normal tasks such as build , test, copy files ,publish artifacts, it's not hard to convert to XAML build. You just need to do some build activities customization. One specific task is Azure Resource Group Deployment Task, there is no such correspondingly in XAML build. However, this task is used to create or update a resource group in Azure using the Azure Resource Manager templates. You could try to use powershell to achieve this part. The most import is using powershell script to publish to Service Fabric.
Actually, when working on TFS2013 XAML build, usually we integrate with Azure Cloud Service not service fabric. There are also related blog with detail steps show how to do it. You could take a reference: Continuous Delivery for Cloud Services in Azure
Moreover, since you are still using XAML build and stay on TFS2013. We encourage you update your TFS version to get latest technology and move to new web-based vNext build system.
On TFS2018, we even removed support for XAML Builds. For the benefit of VNext builds, you could refer to this article: Why You Should Switch to Build VNext
Related
we are planning to use a TFS / MSBUILD on a ARM CPU.
Now we haven't found any information, if that could actually work.
Has anyone ever tried to compile using an ARM CPU?
We want to use a ARM-CPU based server as build server for C#.
For vNext build with TFS2015 and later, parallel build is not support for now.
Details you can refer this question: Parallel build in TFS 2015?
And there has been a feature request in uservoice site:
User Voice:
Ability to build multiple solutions in parallel using vNext Build
With XAML build you could achieve through this way:Building in Parallel Across Multiple Build Agents in TFS2012 for Metro Apps
As for if the build can run on arm based CPU, when you run the build with TFS. You need to have Team Foundation Build Service which has the same operating system requirements as TFS. Hardware requirements for the build service are the same as the operating system on which it is running. Source Link: System requirements for Team Foundation Build Service
So if you could not installed a windows sever system which supported above on your ARM-CPU based server, then you could also not be able to run the TFS build.
I have tried to set up continuous integration to deploy my Azure Service Fabric cluster automatically on git push events in Team Services. I followed the default template for a Team Services Build Definition and a Team Services Release Definition based on this guide:
Set up continuous integration for a Service Fabric application by using Visual Studio Team Services
Here are my settings:
For the most part everything works for the first deployment. After that it throws the following error:
An application with name 'fabric:/<APP>' already exists, its type is '<APP>Type' and version is '1.0.0.20160812.7'. You must first remove the existing application before a new application can be deployed or provide a new name for the application.
From that it appears as though it is trying to completely redeploy the service instead of just upgrading the service. I have searched through all of the settings and tried creating and recreating the tasks but have not been able to resolve.
Has anyone encountered this before?
You need to add or update a publish profile to enable the upgrade mode and use that profile to deploy the Service Fabric after the first deployment is succeed.
To do this quickly, you can right click on your project and select "Publish" from Visual Studio, check "Upgrade the Application" option and click "Configure Upgrade Settings" if needed, and then click “Save Profile" link and commit/push the changes.
Though there is an accepted answer, I would still like to add to this thread. In the approach below we need to edit only the Azure Devops Task. Hopefully this will be useful to others who may encounter the same issue: One simple workaround when you encounter this issue is to change the "Overwrite Behavior" under the Advanced Setting for the build task to "Always". However, care must also be exercised so that if there are services which may already be running - all of them do get upgraded via a rolling upgrade (see second image).
To ensure that rolling upgrade is applied to all the services, in addition to the above, also ensure that the upgrade settings are configured as below:
We have a web app and a desktop windows WPF app.
Windows app sends data to webapp (hosted on azure)
Users download app from website. There are occasionally new versions of desktop apps available.
What is the most efficient way to setup automatic updates for desktop app? We are using github.
I found "releases" in github but I'm not sure how to notify desktop app and how to create an updater. (I guess we need to check for github releases every time app is started. Do I need to use Github api for this?)
What is the best repository structure for releases?
I'm looking for best practicies on how to perform seamless updates to desktop apps. (In terms of repository setup, creating web api to pull version info maybe?)
You can deploy your desktop applications using ClickOnce Deployment mechanism. This will take care of updating the software. Your users download the software from a publicly accessible Internet site. Whenever you have a new version available, you can simply deploy the latest deployment files on the download link. ClickOnce deployed application automatically check for any updated version on that link and prompt the user to download and install the latest version.
From the same MSDN link, one of the problems solved by ClickOnce deployment is facilitating automated updates:
Difficulties in updating applications. With Microsoft Windows
Installer deployment, whenever an application is updated, the user
must reinstall the whole application; with ClickOnce deployment, you
can provide updates automatically. Only those parts of the application
that have changed are downloaded, and then the full, updated
application is reinstalled from a new side-by-side folder.
I was looking into accomplishing the same needs and came across this library which can do what you're asking for;
https://github.com/Squirrel/Squirrel.Windows
There's a lot of configuration, but what you're asking for is not trivial, but maybe you can get some ideas.
For our needs; we're going have our build server (teamcity) create an MSI using a Wix project then the app will download and execute the MSI. Once we go to production we'll move MSI hosting over to some more enterprise-y CDN type setup.
I'm having issues with Continuous Deployment from GitHub in Azure. I have a Shared pricing tier, and the issue goes away if I upgrade to the Basic pricing tier. This is for an ASP.NET MVC 6 application (RC1).
Essentially I get the following error:
http://pastebin.com/PgARgurg
The bit that stands out is:
Restore failed
There is not enough space on the disk.
If I publish directly from Visual Studio to the Shared tier it works fine. It's only when using continuous deployment where it falls over.
Any ideas?
Shared instances have very limited resources, especially around disk size. Continuous deployment integration from GitHub involves bringing down a copy of the code to disk upon every change, and this isn't always cleaned up immediately (or at all). A direct publish to Azure from Visual Studio does clean up the prior deployment packages automatically. The reason that upgrading your tier solves the problem is the dedicated and increased available disk space. You should upgrade to Basic if you decide that continuous integration (and thus disk space) are important to your work.
There's another caveat. Shared Web Apps instances have a limit on Temp Folder size of 300Mb.
An asp.net 5 RC1 application uses more Temp Folder storage than a Beta8 app. It's right now almost impossible to deploy an RC1 through Continuous Integration to a Free App Service.
Basically restored packages size is NOT the same as published packages of an application.
You can understand why this is the case by opening up the restored packages...For example, in the below scenario the published package has only the required content for running the application.
Restored JSON.NET package content:
Published JSON.NET package content:
So probably you should publish the application from your continuous deployment?
I am developing a C#, MVC4, EF5 Code First application on .NET in Visual Studio 2012 and have used the VS publish mechanism to deploy it to an Azure Website with an Azure SQL Database.
I now want to use Git and GitHub for version control and involve others in the project.
However, although I am familiar with using Git in a LAMP environment, I have no experience of using Git with Windows, Azure Websites and a compiled environment.
I would like to use the Azure Website as the production server, another Azure Website as a Staging server, developer Windows machines using Visual Studio for development and GitHub as the central repository.
There is a helpful article here: http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-git/ . I can get my head around what would be needed here for, say, a PHP application on Azure. But I am unsure of the best approach with a compiled application and what I can achieve using Azure Websites and Visual Studio.
A nudge or two in the right direction would be greatly appreciated!
don't publish from VS to azure, instead setup your azure website to pull from the github repo. the deployment process compiles your solution.
watch http://www.youtube.com/watch?v=5NGieL0tinw&feature=youtu.be&hd=1 or read http://vishaljoshi.blogspot.com/2012/09/continuous-deployment-from-github-to.html
Also SocttGu announced this on his blog # http://weblogs.asp.net/scottgu/archive/2012/09/17/announcing-great-improvements-to-windows-azure-web-sites.aspx he also talks about a cool feature of publishing branches, this will nail your requirement for a stage server and production server. Have a stage branch and a production branch and merge to them as desired. see the section "Support for multiple branches"
looks like they added support for private repos finally.
appharbor is a competitor to azure that does something similar.
You are basically introducing a new step with the requirement that the source code must be compiled before it can be deployed to the server. Where you implement this step is up to you. You could:
Ensure that your target server has the capabilities to compile the source code (some Continuous Integration tools could help with this, such as CruiseControl.NET). This has the caveat that the target server be able to compile source code (possibly even requiring Visual Studio to be installed), so that may not be an option.
Check the compiled binaries into source control. You could keep these compiled binaries separate from the main source branch, to keep things clean. Deploy the binaries to the target server.
Some hybrid of the previous two options is also possible; you could set up a Continuous Integration server with CruiseControl.NET, which can check out the current source, build it, and check the resulting binary back into a special branch, then deploy that branch to your target Server.