I was showing someone my blog the other day and they asked when my last post was. I confidently said, “About a month or so ago..” and then I saw it…
Where did all those months go? Maybe I blacked out out or something…
In order to ease into my “blogging resurgence”, I thought I would start with a quick one regarding how I use VSTS and an interesting issue I encountered last night. Since this problem owes me a few hours, I hope it shortcuts somebody else’s pain.
This is a brief post because it’s the second time I’ve had to resolve the same issue and as I don’t think my memory is getting any better, it’s probably better this goes down on my permanent record. 😉
I love a good feedback loop…
Gene Kim talks about the importance of both internal and external feedback loops in his blog post, The Three Ways: The Principles Underpinning DevOps. This includes internal feedback loops such as the result of continuous integration builds, unit testing and application performance monitoring tools like Application Insights. It also incorporates feedback loops from end-users to leverage telemetry and error information to increase the quality of the delivery. This telemetry is the foundation required to prove the outcome of experiments and hypothesis driven development.
In a recent presentation at Xamarin Dev Days 2017 in Melbourne I demonstrated the ease in which teams could adopt DevOps in their mobile application development lifecycles. To do this I embraced our new platform, Visual Studio Mobile Center and showed how teams could leverage it’s API to implement the feedback loops required for hypothesis driven development.
Feedback loops are a critical component of any DevOps transformation. A highly automated build and release cycle is so important but when unexpected circumstances occur the team needs visibility in order to react accordingly.
I love how Visual Studio Team Services provides really powerful dashboards perform this exact role. Below is an example of some of the widgets that VSTS supports out of the box to provide an indication of build and release status. Hosted in a public area, the team can rapidly see what build is in what environment and whether anything has gone wrong.
With Visual Studio Mobile Center the story is a little different. Even if the source code to your Xamarin project is in VSTS, Mobile Center is still performing the build in its magic little black box. This is great because Microsoft maintain the build servers and there’s no need to configure complicated build definitions. The challenge is however, without watching for status emails or going to the Mobile Center portal it’s difficult to see the outcome of a build.
In addition, if the application has additional resources (such as a web API) I may want to see the status of all of the components on one dashboard. Thanks to some native features of VSTS and Mobile Center, we can do just that…
I have been involved in a Conversation as a Platform (CaaP) hack this week and the first thing that seemed to be valuable to the teams was to sort out a CI/CD pipeline for their projects. With the introduction of the Continuous Delivery Tools for Visual Studio from the marketplace this is actually surprisingly easy to do. The tool will perform the following activities:
With that in place, the teams could then hack away together with all of their changes going straight to a live app service that they could immediately visualise their updates with. Let’s take a look…
It’s been a while between posts but the latest focal point for my attention has been HockeyApp. In this multi-part series I will detail my exposure to the framework and identify the solutions to any challenges I faced along the way. As HockeyApp currently doesn’t quite have the coverage across all application types (Android, IOS, Win81, WinRT, UWP, etc) there are some unique obstacles that need to be overcome depending on your application architecture.
In my last post I commenced my journey to integrate our old deployment process with the new shiny VSTS Release Management system. The whole story was about leveraging processes that were already working for us and the flow looked something like this:
The previous step in the process involved getting TeamCity to grab the build output from VSTS and deploy it using our old deployment PowerShell. With this working, my next goal was to be able to trigger the whole process from Release Management so I could either pick the build I wanted to deploy or trigger it from a successful build in VSTS.
I thought, this is going to be mad easy.
Alas, it turned out to be a little more difficult…
My team recently migrated to Visual Studio Team Services and as a result we have a goal to consolidate our deployment processes using the powerful Release Management framework. While this is the goal, for the moment I was interested in somehow getting our current build process in Team City to work along side our shiny new ALM provider.
Visual Studio Team Services and TeamCity. You would think they would go together like chocolate and lobster but with some work I was able to achieve a little unity…
simonlamb.codes 