Xamarin DevOps with VSTS - Getting Started 10 May 2016 on, I've been working to get a Mobile DevOps setup with Xamarin and Visual Studio Team Services/Xamarin Studio/HockeyApp/Xamarin Test Cloud and will be writing some posts to cover this for future reference. These are written from the perspective of a developer getting started rather than an ALM/DevOps professional so some things may not be optimal - I'll try to update the posts with any feedback showing a better way. This post will cover getting started setting up a VSTS Team Project and getting the code into it. Subsequent posts will cover setting up Continuous Integration Builds, UI Testing, Deployments and Monitoring. One thing I have noticed is that the VSTS/Xamarin/HockeyApp tooling is changing at a very fast pace and care is needed to consider the dates of information found on the Internet since a lot of it is out of date. Resources. and.
For that you’re going to need either a souped up text editor (such as Sublime Text, Brackets, Atom, Emacs or Vim) together with OmniSharp for intellisense, or you’ll want to use Visual Studio Code, the new cross-platform IDE from Microsoft that uses OmniSharp with Roslyn and provides Git integration for version control, plus limited.
Tom Walker’s post and Video. GitHub’s. Microsoft Key Points. I started off using Xamarin Studio 6.1 from the Alpha update channel, however I would recommend using the Stable release since I experienced problems with Continuous Integration Builds. Visual Studio Team Services supports TFVC (centralized version control -CVS) or Git Repositories (de-centralized version control - DVCS) - The Git option is the option to choose if you use Xamarin Studio on a Mac.
Visual Studio Team Services is available free for 5 users or less, this does have some restrictions such as the number of build agents and number of build minutes (currently 240 per month). Visual Studio has a great integration with VSTS and support for Git repositories. Xamarin Studio is less well integrated but I'm really liking that it's lightweight and fast. I'll be writing the posts from the perspective of a Xamarin Studio user but most things will be applicable to Visual Studio users. VSTS uses email addresses to sign in and these contain an '@' symbol which presents problems working with Git. Visual Studio users will have no problem but using any other Git client you will need to generate an alias using the VSTS Alternate authentication credentials. I found and posts useful here.
Having to keep entering the username and password details will quickly become tiresome. Microsoft provides the to overcome this problem. Create a Visual Studio Team Services Team Project Get started by going to the and click on the button ‘Get Started for free’ under the Visual Studio Teams Services (VSTS) column.
Login in with the Microsoft account you wish to associate with VSTS The page below is displayed enter a name for the site Url. Note that the default Version Control system is Git, this is the option to choose if you are using Xamarin Studio on a Mac. Click on the ‘Continue’ button. When the VSTS site has been created the welcome page below will be displayed:- Note that a team project titled ‘MyFirstProject’ has been created. The process type for the project will be ‘Agile’, generally I’m working with the Scrum process so we will delete this team project and create a new one. Close the dialog using the ‘x’ button in the top right. Click on the Team Services in the top right and the Overview page shown below will be displayed:- Click on the ’New’ link under the ‘Recent projects & teams’ heading and the ‘Create new team project’ dialog will be displayed as shown below, enter a name and description and set the Process template as required, in this case we will use Scrum:- Click the ‘Create project’ button.
When the creation is completed the confirmation dialog below will be shown:- Click the ’Navigate to project’ button and the ‘Welcome’ dialog below will be shown:- Setup the Git Credentials Click the ‘Add code’ button and the ‘Explorer’ tab of the ‘Code’ page will be displayed as shown below:- Note the ‘Generate Git credentials’ button. This will create an Alternative authentication credential which is a username alias.
Because the sign-in to VSTS is with email addresses which contain the ‘@‘ symbol this presents a problem when using Git on Mac OSX. Click the ‘Generate Git credentials’ button and enter a username and password. Next click the ‘Save Git Credentials’ button. As can be seen in the image below in this instance I have already created an alias with the name ‘richard’ so we can navigate to the security page, which is another way of accessing the security credentials:- Click on the link ‘thexamarinjournal’ and then select the ‘My Profile’ option as shown below:- The ‘Edit Profile’ page will be displayed as shown below:- Next click on the ‘Security’ tab:- Click on the ‘Alternate authentication credentials’ and the page below will be displayed with a recommendation to use personal access tokens. Check the ‘Enable alternate authentication credentials’ and the edit boxes will be displayed, fill these in with something memorable and short as you could be typing these in a lot:- Click the ‘Save’ button, then the ’Team Services’ link in the top left title bar to get back to the overview page.
![Toby mac Toby mac](/uploads/1/2/5/4/125497994/722526031.png)
Click on the XamarinDevOps entry under the ‘Recent projects & teams’ section. The Team project page will be shown again:- Click on the link ‘Add code to your repository’ and we get back to the ‘Code Explorer’ page:- Clone/Checkout the Repository Next start Xamarin Studio. Next select the ‘Checkout’ option of the ‘Version Control’ menu:- Now the ‘Select Repository’ dialog will be displayed:- Now paste in the Url copied from VSTS into the Url textbook:- Now press the ‘Checkout’ button and a ‘Git Credentials’ dialog is displayed:- Enter the alias that we created in VSTS:- Click the ‘OK’ button.
As an alternative we could use the git command line command git clone A good reference is. Also shows another alternative using the Publish option. Create a new solution Now we can create a solution to add to the VSTS Git repository. Click the ’New Solution’ button.
Select a ’Single View App’ for iOS and Android:- Click the ‘Next’ button and give the app a name:- Click the ’Next’ button and use the ‘Browse’ button to select the directory ‘XamarinDevOps’ which we just create via the git clone command. Check the ‘Use git for version control’ option. Click the ‘Create’ button. Check the solution builds. Commit To The Local Repository Click on the ‘Remote Sources’ tab. Now click the ‘Add’ button. Enter the Url Now click the ‘OK’ button.
The Remote Sources tab should now contain the ‘XamarinDevOps’ repository as shown below:- Select the ‘Review Solution and Commit’ option on the ‘Version Control’ menu:- The Version Control Status page will be displayed as shown below:- Click on the ‘Commit’ button and the ‘Commit Files’ dialog will be shown:— You may get a ‘User Information Conflict’ dialog, choose the most appropriate option. I used the ‘Use the Xamarin Studio configuration’ option.
Click the ‘OK’ button. Enter the alias we created earlier in the Git Credentials dialog:- Push Changes To The VSTS Repository Now that we have committed the changes to the local repository we need to push the changes back to the remote VSTS repository. So select the 'Push Changes.' Option of the 'Version Control' menu. The 'Push to Repository' dialog is shown.
Click the 'Push Changes' button. Now if we go back to the VSTS 'Code' page and select the 'Explorer' tab we can see that the solution has been pushed upto the VSTS Git repository:- The Microsoft documentation is a useful reference showing how to get started with working with Git branches and provides other links for working with Git. As the post is getting quite long I will end here and detail the creation of Continuous Integration Builds for Xamarin.Android and Xamarin.iOS in the next post. Read by this author.
Contents. On-premises vs. Online Team Foundation Server is available in two different forms: on-premises and online. The latter form is called (formerly Visual Studio Online before it was renamed to Visual Studio Team Services in 2015). The cloud service is backed by Microsoft’s cloud platform,.
It uses the same code as the on-premises version of TFS, minor modifications, and implements the most recent features. Azure DevOps requires no setup. A user using a to set up an environment, creating projects and adding team members. New features developed in short development cycles are added to the cloud version first.
These features migrate to the on-premises version as updates, at approximately three-month intervals. Architecture Server architecture Team Foundation Server is built on, scalable architecture. The primary structure consists of an application tier responsible for processing logic and maintaining the web application portal (referred to as Team Web Access or TWA).
TFS is built using web services. These may be consumed by any client, although the client object model is recommended. The data tier and application tier can exist on the same machine. To support scalability, the application tier can be load balanced and the data tier can be clustered.
If using 2012, AlwaysOn SQL Server Failover Clusters and Availability Groups are supported which allows for geographic replication of data. The primary container is the project collection. A project collection is a database that contains a group of Team Projects. The Project Collection is another scalability mechanism, in that each collection can be placed on different SQL Servers or SQL Server instances. 'Oe' configuration database per TFS instance stores project collection metadata. Data from the project collection databases is aggregated into the warehouse database, which denormalizes the data in preparation for loading into an Analysis Services cube. The warehouse and the cube allow complex trend reporting and data analysis.
TFS can integrate with an existing farm. SQL Server Reporting Services are supported for more advanced reporting against the data warehouse or the Analysis Services data cube. These installations can be on the same system or on different systems. Build servers, lab management servers, release management servers and proxy servers (to reduce some of the load on the application tier), test machines and load test machines can also be added to the infrastructure. To support teams requiring enterprise project scheduling, TFS also integrates with, which allows enterprise level portfolio management, resource management and project tracking. Extensibility Microsoft provides two good standalone redistributed for connecting to TFS. One is a SDK, the other is a SDK.
These APIs allow for client connectivity to TFS. Because TFS is written on a service-oriented architecture, it can communicate with virtually any tool that can call a web service. Another extensible mechanism is subscribing to system alerts: for example, alerts that a work item was changed, or a build completed. There are approximately 20 preconfigured alerts, and teams can configure as many additional alerts as needed.
When used in an extensible scenario, these alerts can be sent to a web service, triggering actions to alter or update work items (such as implementing advanced business rules or generating work items programmatically based on a given scenario). The data warehouse can also be extended through the creation of custom data warehouse adapters. With the introduction of TFS 2012, custom add-ins can also be created for Team Web Access, called Web Access Extensions. Clients TFS supports Visual Studio 2010 and later, (MTM) 2012 and 2013. Eclipse, older versions of Visual Studio, and other environments can be plugged into TFS using the Microsoft Source Code Control Integration Provider (MSSCCI Provider – pronounced “Miss-Key”). These tools provide full access to the features in TFS. And are also supported to help manage work items which allows for bulk update, bulk entry and bulk export of work items.
Microsoft Project can be used to schedule work when conforming to a waterfall software development methodology. Both Excel and Project support bi-directional updates of data. This allows, for example, project managers to put a schedule in Project, have that work imported into TFS where developers update the work and then the schedule can be updated without the project manager having to perform extra work. With Team Foundation Server 2012, was also integrated with TFS to enable rapid storyboard development to help with the requirements management process. The integration provides extensible storyboard shapes that can be used to build any type of interface mockup that can then be animated with PowerPoint’s built-in functions.
These storyboards can then be linked to work items. In an effort to handle the growing geographic dispersion of teams and to involve stakeholders earlier and more often in the process, Microsoft added the Feedback Client.
This tool allows users to exercise an application, annotate what they are seeing with audio and video, capture screens and provide contextual feedback to the development team. This provides specific feedback on the functions of an application from a users’ perspective without requiring meetings and demonstration sessions. TFS also provides for command line tools for both Unix and Windows environments.
![Studio Studio](/uploads/1/2/5/4/125497994/369999008.png)
The Power Tools for TFS include a integration that allows users to check files in and out, add files and perform other basic tasks by right-clicking on a file or folder. Work items At the heart of TFS is the 'work item'. A work item represents a thing – it can be work that needs to be accomplished, a risk to track, a test case, a bug or virtually anything else a user can imagine. Work items are defined through the documents and are highly extensible. Work items are combined into a Process Template that contains these and other pieces of information to provide a development framework. TFS includes Process Templates for the for Agile, Scrum and CMMI.
Teams can choose to use a built-in template or one of the many templates available for use created by third parties. Process templates can be customized using the Process Template Editor, which is part of the Power Tools. Work items can be linked to each other using different relationships to create a hierarchical tree of work items or a flat relationship between work items.
Work items can also be linked to external artifacts such as web pages, documents on a file share or documents stored in another repository such as SharePoint. Work items can also be linked to source code, build results, test results and specific versions of items in source control.
The flexibility in the work item system allows TFS to play many roles from requirements management to bug tracking, risk and issue tracking, as well as recording the results of reviews. The extensible linking capabilities ensure that traceability from requirements to source code to test cases and results can be accomplished and reported on for auditing purposes as well as historical understanding of changes. Source control Team Foundation Server supports two different types of - its original source control engine called Team Foundation Version Control (TFVC) and with the release of TFS 2013, it supports as a core source control repository. Team Foundation Version Control TFVC is a centralized version control system allowing teams to store any type of artifact within its repository. TFVC supports two different types of workspaces when working with client tools - Server Workspaces and Local Workspaces. Server workspaces allow developers to lock files for check-out and provide notification to other developers that files are being edited.
A frequent complaint for this model is that files on the development machine are marked as read-only. It also requires developers to 'go offline' when the server can't be contacted. Local workspaces were designed to avoid these problems.
In a local workspace scenario files are not read-only and they do not have to be checked out before working on them. As long as the files are on the developer's local machine, it doesn't matter if the server is connected or not. Conflicts are dealt with at time. To improve performance for remote clients, TFS includes the ability to install. Proxy servers allow source control contents to be cached at a site closer to the developers to avoid long network trips and the associated latency. Check-ins are still performed directly against the TFS application tier so the Proxy Server is most beneficial in read scenarios. As part of the source control engine, TFS supports a number of features to help developers ensure the code that is checked in follows configurable rules.
This rule engine is called a Check-in Policy. There are several out of the box policies such as the Changeset Comments Policy which will not allow a check-in unless the developer enters a check-in comment. These policies are extensible and can be used to examine all aspects of the code being checked in, the comments and the related work items. TFS also supports a Code Analysis feature that when used independently is known as. The inclusion in TFS means that the analysis can run against code checked into the server and during automated builds.
Git With the release of TFS 2013, Microsoft added native support for. This is not a Microsoft specific implementation but a standard implementation based on the libgit2 library. This is the same library that powers the popular and the code is freely available from GitHub.
Because Microsoft took the approach of using a standard library, any Git client can now be used natively with TFS (in other words, developers can use their favorite tools and never install the standard TFS clients). This allows tools on any platform and any IDE that support Git to connect to TFS. For example, both and support Git plug-ins.
In addition, if developers do not want to use Microsoft's Team Explorer Everywhere plug-in for, they can choose to use eGit to connect to TFS. Using Git does not preclude the benefit of using TFS work item or build system. When checking code in with Git, referencing the work item ID in the check-in comment will associate the check-in with the given work item. Likewise, Team Build will also build Git projects. One of the major reasons to use TFS as a Git repository is that it is backed by SQL Server and is afforded the same protection as Team Foundation Version Control. This gives developers some choices when choosing the type of project and work style that works best for them. Reporting Reporting has been a core component of TFS since its initial release in 2005.
The reporting infrastructure consists of a data warehouse (TfsWarehouse) which is a relational database and a SQL Server Analysis Services data cube. Both of these sources are available for reporting through SQL Server Reporting Services when this option is installed. Since these are standard database and cube structures, any tool which can point to these data sources can report from them. This includes tools such as Cognos, Tableau, Excel and other reporting tools. Included with each out of the box process template is a set of reports for reporting services which cover Build information, Test results and progress, project management, agile reports (Backlog Overview, Release Burndown, Sprint Burndown and Velocity), bug and issue data.
New reports can be created using Report Builder for SSRS and any of the existing reports can be modified. More specialized reporting is available for load test results. This data is available directly within Visual Studio and can be exported to Excel for detailed analysis.
TFS 2013 introduced a new feature called 'light-weight reporting' which provides for the ability to create real-time reports based on query results and which do not rely on the warehouse or cube. TFS 2012 (and continuing into 2013) offers real-time burndown, velocity and CFD diagrams directly within Team Web Access. Team Build Team Build (prior to TFS 2015) is a build server application included with Team Foundation Server. Two components make up Team Build -. MSBuild is a declarative XML language similar to. WF was added to the build process starting with TFS 2010; prior to that only MSBuild was available. The build capabilities have continued to evolve with each subsequent release of TFS.
In TFS 2010 and 2012, the WF templates files were stored in source control and could be edited and versioned directly from source control. In TFS 2013, these files were removed to eliminate clutter and streamline the build process. The WF templates can still be downloaded, edited and stored in source control if desired and TFS 2013 does not break existing TFS 2010 or 2012 build process templates. With the support of in TFS 2013, Team Build has been enhanced to allow automated building of Git projects as well as TFVC projects.
Windows Workflow controls the overall flow of the build process and TFS includes many pre-built workflow activities for managing common tasks that are performed during a build. MSBuild is the markup language that is found in the.proj (csproj for C# projects and vbproj for Visual Basic projects) files. The build system is extensible with users being able to create their own workflow activities, the ability to inject MSBuild into the process and to execute external processes. The workflow nature of the build allows for unlimited flexibility, but it may take some work to achieve that flexibility. Shared and open source projects have been started to build community backed activities to enhance the capabilities of Team Build.
The build process can be configured for various types of builds including scheduled builds, gated check-in and rolling builds. A gated check-in build will shelve code that a developer checks in, perform a 'get latest' on the server code and perform a build. If the build succeeds, the code is checked in on behalf of the developer who submitted the code. If the build fails, the developer is notified and can fix the code before trying another check-in.
Builds have retention policies with them so that they do not accumulate when not needed (or builds can be directed not to produce any saved output) or build output can be locked and saved forever. New with TFS 2013 is the ability to check in the build results into source control.
This was a necessary enhancement to support automated builds on the TFS service where there is no drop location to place the builds. In the on-premises version build output can be configured to end up in any accessible shared folder location. The build process in TFS is also part of the traceability mechanism in that Team Build brings together many of the artifacts that are created and stored in TFS. Assuming developers associate source code with work items on check-in, Team Build has the ability to report on the changes in each build - both source code changes and work item changes as well as test results (this includes results as well as automated functional testing (CodedUI) results). As bugs and PBIs are resolved and integrated into builds, the work items which track these artifacts are automatically updated to indicate in which build they were successfully integrated.
Combined with the testing tools, testers then get an integrated view of what code was changed in each build, but also which bugs, PBIs and other work changed from build to build. In Team Foundation Server 2015 and with Visual Studio Team Services, Microsoft has reinvented the architecture for the build engine to be based on a cross-platform friendly Node.js application. Windows, Mac, and Linux build agents are currently supported. Visual Studio Team Services provides for elastic build capabilities via build hosting in Microsoft Azure.
Release management In mid-2013 Microsoft purchased a product called InRelease from InCycle Software. InRelease was fully incorporated into Team Foundation Server 2013.
This capability complemented the automated build and testing processes by allowing a true solution. The tools were re-branded 'Release Management' for TFS 2013. The Release Management capabilities give teams the ability to perform a controlled, workflow (provided by ) driven release to development, test and production environments and provides dashboards for monitoring the progress of one or more releases. Microsoft has rebuilt Release Management for Visual Studio Team Services and on-premises version of Team Foundation Server with the new changes in 2015 Update 2. The new version of Release Management leverages the web browser as the client and relies on the same agent architecture as Team Foundation Build. Release Management enables capabilities for Team Foundation Server. History This first version of Team Foundation Server was released in 2005.
Product name Form Release year Visual Studio 2005 Team System On-premises 2005 Visual Studio Team System 2008 On-premises 2008 Team Foundation Server 2010 On-premises 2010 Team Foundation Service Preview Cloud 2012 Team Foundation Server 2012 On-premises 2012 Visual Studio Online Cloud 2013 Team Foundation Server 2013 On-premises 2013 Team Foundation Server 2015 On-premises 2015 Visual Studio Team Services Cloud 2016 Team Foundation Server 2017 On-premises 2017 Team Foundation Server 2018 On-premises 2017 Azure DevOps Cloud 2018 Azure DevOps Server (v.Next) On-premises 201? See also. (VSS)., a Windows client or server side extension to TFS that allows access to TFS revision controlled items from client applications. References. Retrieved 2013-10-15.
Retrieved 26 May 2017. Retrieved 2013-10-15. Retrieved 2013-10-17. Retrieved 2013-10-17. Retrieved 2013-10-17. Retrieved 2013-10-17. Retrieved 2013-10-17.
Retrieved 2013-10-17. Retrieved 2013-10-17. Retrieved 2013-10-17. Retrieved 2013-10-17. Retrieved 2013-10-17. Retrieved 2013-10-31.
Retrieved 2013-10-31. Retrieved 2013-10-17. Retrieved 2013-10-17. Retrieved 2013-10-17. Retrieved 2013-10-17.
Retrieved 2016-05-17. The Next Web. Retrieved 2013-11-15. External links.