Visual Studio Online Wunderlist extension on GitHub
With the joining of Wunderlist with Microsoft an obvious scenario falls in place, a connection between Visual Studio Online and Wunderlist (team tasks versus personal tasks). Take carefully planned Team activates in Visual Studio Online with you, by putting them together with your daily tasks in Wunderlist, ideal for the busy programmer.
With this idea a weekend project has started. I already planned (on my Wunderlist task list :-) to learn more about the Visual Studio Online extensibility model.
This is an overview video of the functionality.
On GitHub you can find the sources.
For the implementation I mainly used the VSO examples together with the Wunderlist API docs and a I toke some C# from 6wunderkinder/Wunderlistchen (thx Christian Lang)
Only the happy flow from VSO to Wunderlist is implemented, it is far from production ready. I wonder if it ever will be, also because Wunderlist works on an integration point with Zapier. That gives us (VSO users) an easier integration point than building it yourself.
Sogeti finalist Microsoft Application Lifecycle Management Partner of the Year 2015
Happy to mention we got awarded as finalist for the Microsoft Application Lifecycle Management partner of the Year 2015.
See the Worldwide Partner Conference site.
The credits go mainly to or adoption accelerator for Dev and Test on Azure service, OneShare.
It is a nice follow up on or 2011 Country partner and or 2013 ALM partner awards.
Organize, start, stop, schedule (and snooze) Azure VM’s and stay within your Azure MSDN benefit boundary.
I can’t use my MSDN Azure benefit anymore, because I forgot to switch off a Virtual Machine.
It happens too often.
Although it is easy to schedule a virtual Machine via the Azure portal (see: Script Center and azure automation ), users still forget to configure it or don’t take the time or simply don’t know how to do it.
To make it easier to organize, start, stop, schedule (and snooze) Azure VM’s and stay within your MSDN Azure benefit we a light version of the O365 App ‘OneShare’.
Development and Test on Azure with OneShare.
OneShare is a solution and service build by Sogeti for Development and Test teams who are using Azure for their environment needs (Cloud usage flavors for Development and Test teams.).
OneShare provides insight, control and self servicing on top of Azure within Office 365 and with Visual Studio Online.
Every project within OneShare gets a Visual Studio Online account, an Azure Subscription and a Office 365 portal.
The OneShare Solution connects these three together, which gives the team a consistent view and entry point on all the resources a team needs to be Fast and Flexible.
Azure and Office 365 MSDN benefit for Development and Test on Azure.
OneShare for Azure MSDN benefit is a light version of the OneShare Enterprise edition which is connected to an Azure Enterprise Enrolment (and has many more features see this video). For now it contains the start, stop, schedule features (more will be added every sprint).
How To setup.
Activate your Azure and Office 365 MSDN Benefits.
Download the OneShare App.
When your Office 365 developer tenant is created get the OneShare App, download it from here (later I’ll publish it to the Office 365 Store, which gives an easier model for distributing).
OneShare App : http://1drv.ms/1Mk7WTF
In the MSDN Office 365 tenant you get a developer site by default, you can upload the OneShare App in this site or create an AppCatalog site and upload it there. The difference is that from the developer site you only can use it there, via the AppCatalog you can put it on any site you have in your tenant.
When you have uploaded, deployed and trusted the OneShare App to a site, you can add the VM State AppPart to the site. Go to ‘edit’ (upper right corner of the site) and select, Insert, AppPart, Azure Virtual Machine.
Save the page (upper right corner) and configure the OneShare App for your Azure Subscription. Click on the ‘Azure Virtual Machine’ header of the AppPart. This brings you to the configuration section.
Select Project Settings and download the certificate. This certificate needs to be uploaded to the Management Certificate Store of you Azure Subscription.
When you want to be updated on OneShare state fill the Mail Contact.
NOTE: using Azure Management Certificates is not the most ideal way of authentication against an Azure Subscription. The OneShare Enterprise version authenticates against Azure Active Directory which gives a more fine grained control. When you remove the certificate from the store, OneShare can’t access the subscription anymore, this is the way to opt out.
Save the project settings, will bring you to the VM Properties screen. In this screen you can edit the properties of the VM’s.
Push ‘Refresh’ when you want to collect existing VM’s from your Azure subscription.
Per VM properties can be set for category, estimate, start, stop and notification.
The NoStartStop Schedule option is useful when you want to give other people access to the SharePoint site where the OneShare app runs on. When you add a OneShareAdmin group to the site and make yourself member. you can switch of the capability for other users to start and stop a Azure VM.
On the AppPart the settings are visualized as.
The VM Status History page shows the usages history of the VM in a graphical overview. A easy way to figure out how the VM’s are used in your subscription.
Have fun with it. while the OneShare Enterprise version has support this version is As-Is no support, no guarantees are provided and without warranties of any kind.
But, I’m happy to answer all questions.
You also can use UserVoice http://oneshare.uservoice.com/
For the whole setup, also the one via an AppCatalog see this YouTube video. (without sound, some construction going on around the house, too much noise ;-)
OneShare promo video …
Already did a lot of post about Development and Test on Azure … see small list below. Now a promotional video about our Dev and Test services …
Make your team cost aware … cost driven development.
Cost is an interesting thing when developing on and for Azure.
A team now has direct influence on the run cost of the different environments. Not only development and test but also staging and production is in their influence zone.
With the right insight in environment cost a team can make architectural decision based on environment billing information.
For example, within Azure you can put all the code in an Azure VM, which is easy (lazy) and pretty expensive when you have them On all the time. Specially when you have Azure VMs for al stages.
See graph below, a team before 22 November everything on VM’s and always on, after 22 November with some more awareness the costs went down with almost 70%.
Project Azure costs, before and after being aware of the environments costs of their environments.
Other example, moving functionality from VMs to Azure Cloud Services lowers the price a bit (and finally also lower the operational costs). But moving Data from an Azure SQL Server to Table Storages is also a very beneficial move. Or moving a Worker Role to Azure Schedule Jobs or Web Jobs really pays off.
Below the Azure Billing costs of a project which tightly makes architectural decisions based on costs. For the team it is a challenge to constantly lower the daily cost.
With the daily updated Azure Costs insight they can see bad decisions (see spike) and good decisions (the big drop) immediately.
Also the slight rising of daily costs over time is something to pay attention to. Although the teams adds new functionality constantly the costs stays almost the same on a daily base.
Teams can get with Azure much more cost aware. For this to happen teams need daily updated insight in costs.
Read more: http://clemensreijnen.nl/post/2015/01/17/Insight-and-Self-Servicing-needs-for-Dev-Test-Teams.aspx
The DevOps battle field … provision, configure and deploy environments.
The current battle field in the software industry is among the provisioning and configuring of environments, specially cloud environments.
To live the DevOps dream one of the skills a team must have is the capability to be fast and flexible in the provisioning, configuring and usages of environments.
These environments cover not only test environments but also the complete needed ALM infrastructure and the team member workspace. See this post: Cloud usage flavors for Development and Test teams.
An interesting part of the battle field gives this survey Deployments in .NET 2014/2015 Report
although the list of tools is pretty long it isn’t compete and more are coming almost on a daily base.
Which deployment tool and technology to choose is really hard and often depends on the experience of a team member or the tools the operations department used to use.
Infrastructure as Code
While Deployment technologies is one part of the battle field and other part and even more important is the provisioning and configuring of environments. The Infrastructure as Code technologies.
For example this is a small list of tools which automate the provisioning and configuration of environments.
To make all these technologies of provisioning, configuring and deploying valuable it must be done in relation to a release, to customer value.
Release Management tools which support the flow and relate it to functionality, reports and tests are a must for teams. Support of tools which help to integrate the environments and releases in to the complete Application Lifecycle.
Microsoft Visual Studio Release Manager is one of these tools, another one is HP Codar. And probably there are many more….
Investing leaning time (and money) in the moving target of Provisioning and Configuring (Cloud) environments is a must for every team. As with all investments, it can be a waste of money. When a technology or tool doesn’t take off, or the capabilities aren’t what you expected.
It is for teams often hard to get a grip around what to do, which technology, which tools. My advice: start by asking the operations department (the Ops part of DevOps)is a good start to make a decision.
Insight and Self Servicing needs for Dev & Test Teams
Two important aspects must be given to teams who work from and on Azure. Insight and Self Servicing.
Insight in usages of Azure resources (and money) in relation to the team activities. When you are in the automation business, you are lazy by default. Team members will forget to switch off machines. Team members will leave test environments running, even when there aren’t any test runs going on or planned.
When you give team members direct insight how they are consuming Azure resource in relation with their activities, they will pay a lot more attention to it.
With this insight the lower cost, pay per use, scenario will really take off.
Self servicing and some help with it. Team member who are busy for days to setup their work machine isn't from this age any more, even teams who are busy for days setting up (and configuring) the complete test infrastructure or automate build and test environments isn’t accepted by customers anymore.
The creation of machines on Azure is pretty easy, but still additional software installing and configure for example networks takes a lot of specialized knowledge not every team member has.
Making it easy for every team member to create environments, also the ones without PowerShell knowledge or even Azure services knowledge, is key for the success of using the Cloud for your teams.
Dev and Test Teams Portal.
At Sogeti we created the OneShare service and solution for teams. An O365 hosted portal where every team/ project gets a site, a Visual Studio online account and an Azure sub-subscription, all connected with each other. to give insight and self servicing for every team member.
For more details watch this video…
DevOps technical meeting video: Ent DevOps | Cloud Teams | Dutch harbour case | Docker containers for DevOps
Live streamed on 16 Oct.. 2014
Welcome to the Live stream of our DevOps technical meeting!
Program is as follows:
18.00-18.45u Introduction & Enterprise DevOps (Dave van Herpen, Sogeti NL)
18.45-19.30u Cloud Team, OneShare (Clemens Reijnen, Patriek van Dorp, Sogeti NL)
19.45-20.30u DevOps collaboration in the Dutch harbour (Peter Siepel, Schuberg Philis/Loodswezen)
20.30-21.00u Use of Docker containers for DevOps practices (Benoît Wilcox, Laurent Guerin, Sogeti France, via webcast)
3 Challenges when Testing from and on the Cloud.
When adopting the Cloud for your test work it comes with several challenges. Looking at the different usages flavors of the cloud for teams, read: Cloud usage flavors for Development and Test teams, then every flavors has its own challenges.
Challenge 1: Team Workspace in the Cloud – Test Environment On Premise.
The scenario is that the team adopted Team Member Workspace on Azure, but the infrastructure (test environments) are staying on-premise.
The planning, preparation, specification and execution of the test work takes place on the team member workstation which is hosted in the Cloud.
The challenges is that the execution of test are triggered from the public cloud and the test runs on the private data center. There needs to be a connection between the team member workstation and the test environment. The same counts for automatic test runs.
Solution: make a network connection between Azure and the On-Premise datacenter. Often a very long discussion with the internal infrastructure people is needed to get this working.
You can create a Site-to-Site VPN, for connecting datacenters to an Azure site or Point-to-Site VPN, when connecting a single machine to an Azure site.
Challenge 2: Acceptance Test Infrastructure in the Cloud – Production On Premise.
the scenario, all environments (development and test) are on Azure except production, this one still lives on-premise. The challenges is to get the test and acceptance (on Azure) environments as equal as possible to the production (on prem) environment.
Solution: The best solution is the usages of the same installation scripts for production as for acceptance and test. Make PowerShell DSC scripts for and re-use them for every environment.
there is also a need for stubs to make testers need to focus on writing isolated tests, which will make more systems valid. Still not all tests can run on Azure Test Infrastructure (performance and load tests won’t give valid results).
the worst case scenario is that an additional pre-production environment needs to be created on-premise for tests which couldn’t be validate in the cloud.
Challenge 3: ALM Infrastructure in the Cloud – test, acceptance and production on- premise
The scenario: The team consumes their ALM infrastructure from the Cloud and use on premise workstations.
Actually from a technical perspective there isn’t a challenge in this scenario. The only need is reliable https connection between the Test case repository (ALM Infrastructure ) and the test environments.
Interesting in this scenario can be the test data. There is probably a security reason why the environments (test, acc and prod) are in the local datacenter. When the test cases, test data and test results are stored on Azure, the security regulations probably also count for that data.
Often production data is used as test data resulting in a no go for this scenario. A solution is to anonemize the test data.
these where just three challenges for the three different components of Cloud usages for Dev and Test on Azure.
There are many more challenges, maybe in another post.
Cloud usage flavors for Development and Test teams.
The cloud for teams have many forms.
Teams can simply use a virtual machine on Azure to work from, the team member workspace flavor as I call it.
Or, they can use the bug tracking database, requirements management, and scrum board from the Cloud. In either a SaaS way, like Visual Studio Online (www.VisualStudio.com) or as an IaaS solution (see Practical guidance for TFVC and TFS on Azure IaaS). Both are the ALM infrastructure in the cloud flavor of Cloud usages by teams.
Another way teams can use the Cloud for their work is that they use it for their Development and Test Infrastructures. For example, when you develop a system for an On-Premise SharePoint farm team members need to have a SharePoint Farm. Developers need the infrastructure for development, debugging and integration, testers for sure to run tests for the system in development. It is the Development and Test Environments flavor.
When adopting the cloud for your Development and Test work, all three flavors are interesting to look at. You can consume them separately but when using all together you are really riding the cloud wave.