VSTS is the new name for what was once called Visual Studio Online – a collaborative development platform that allows for planning (Scrum, Agile or CMMI), development, testing and building all integrated through a single service. Changing development and planning tools is of course a big challenge for many teams especially those who are sitting behind a corporate firewall. How do we integrate our tools, how do we migrate our work items, how do we get Continuous Integration and Continuous Delivery working in this new world?
I’ve often found that with these types of migration projects it’s always best to tackle this process in small, manageable chunks. We identify the main workstreams and look to see what can be migrated when to reduce impact on projects and deliveries. With luck most teams won’t even notice that they are being migrated, we give them plenty of warning, we agree timelines, provide up-front support and reassurance before, during and afterwards. It’s a stressful time for developers, testers, project and delivery managers because you’re essentially taking away the tools of their job. Often this replacement is very different to the original tool and not everyone will be happy about the changes that they are forced to deal with.
Within the current project I’ve broken down the migration into streams by function, product and also by technology. So for example we are migrating from a workload management tool into VSTS, and we are also migrating source code from SVN and TFS on-site into VSTS. There are trial migrations to be planned and stakeholders to be aligned (yes) but also there is also a great deal of FUD flying around.
FUD manifests itself in many ways but chief among them is the ability to believe that anyone with a shred more information than you is the expert on the whole migration process. If it’s your job to manage to migration process then you can use this in your favour purely by appearing to have all the answers even if you don’t. As long as you can keep calm and keep moving the traffic along in an orderly manner you’ll be able to migrate your users with the minimum of fuss. I call this FUD alignment. Because with a tools migration you don’t always have the answers until you actually try it – so your job is to get everyone to a point that they trust you enough that they are willing to help you try and find these answers. This is how all migrations work – you can minimize the risks and get better approximations but there are always unknowns.
So we have some legacy, gnarly source code in SVN maintained one project team and alongside that we have some shiny new code in TFS on-site.
Both teams have to go to VSTS but the Shiny News want to go first, and they want to use everything it has to offer. The only problem with this is that VSTS build integration is so new in our organisation that it isn’t fully ready for them yet – we have no online artifact repository available, we have no corporate licence server available. What we do have already in VSTS Build is the choice between the old school XAML build process and the new, more fully flavoured vNext builds. vNext appears to offer more integration – artifact build and alignment, better testing options. It would appear that vNext builds would make the build definition process simpler and more intuitive eventually however for the moment it’s just out of our reach so we need an alternative.
Because the Shiny News are already using TFS on-site for work items and source code the migration to VSTS is pretty much effortless. Our source code and work items are now in the cloud but for our build agent still has to run on-premise. Because of this configuration we are forced to integrate VSTS with our existing TeamCity instances using Team Explorer Everywhere. VSTS uses a token based authentication mechanism (PAT) via a corporate-linked VSO account. You must generate a PAT token and then persaude on-site TeamCity to talk via the corporate firewall to VSTS. TEE was our first migration target but after providing some feedback to JetBrains support we also received a patch that allowed our Linux build server to talk successfully to VSTS.
So now for one of our projects we have a partial migration, to whit:
- We have taken source code and work items into the cloud
- We’re still building on premise but CI is working
We have some progress but it’s perhaps as not as much as I would have liked. A lot of this comes down to that FUD alignment again – with cloud solutions comes more FUD, and more stakeholders. Planning immediately becomes that bit more complex than it once might.
As you can see even in the simple case with relatively new and clean code it can take some time and effort to replicate a CI process even on-site. And this solution doesn’t even have facility for gated check-ins or for feature branching as we would like – it’s limited still. We want to take this further and eventually build in-the-cloud but we’ll need to dedicate more and more time to clearing up the nuget and license dependencies, to working behind a corporate proxy, to working alongside many stakeholders in many different teams both within our organisation, within Microsoft and through partners. Aligning teams and requirements across architects, development teams and professional services departments is complex as is working out who is responsible for paying for it all.
And there is the rub.
The main driver for a lot of these cloud based collaboration efforts is in order for departments to make cost savings. Offboarding developers to the cloud, freeing up expensive servers and desktops and allowing for easier, remote collaboration is the dream. It’s important to realise that making these services available outside the enterprise is often breaking new ground in terms of security and architecture. This makes the process to support these systems complicated, risky and potentially expensive as is the migration process. Additionally you are dependent upon services which are not always the most reliable.
We will be pushing forwards with our cloud efforts and I’ll report back when we are further along the process. There are definitely huge positives to be taken from this exercise but just as CI is not a silver bullet, neither should we view the cloud as the thing that’s necessarily going to save us time, money and effort either in migration or potentially after it.