This blog post describes our way from various source control systems to Visual Studio Team Services.
When I started to work at PALFINGER in 2010 we were a group of 9 software developers which were responsible for the PALSOFT products and the PALFINGER Extranet. In 2010 every application had a different tooling set for source control and product development. We used Source Safe, SVN, File System (a lot of Backup folders), Custom SharePoint Ticket System, Excel Backlogs and much more surrounding tools. Some years later we decided to migrate our existing tools to Team Foundation Server 2012 to establish a standardized system across the department. At this time, we were more people on board and the Software Development Department was already divided in four teams (Calculation Apps, PALDIAG, Web & Mobile and PLM/CAx). We migrated most of our applications to TFS but for my Web Team the TFS didn’t bring any advantages compared to our existing SVN solution.
- We had optimized the deployment process based on SVN tags
- We started to use Team City as our CI which CI capabilities were 1000 x better than TFS2012
- Working with external suppliers was much easier because SVN was hosted outside of our corporate network and TFS not.
- Besides this problem we stuck to the TFS version because of our internal Database Cluster which didn’t support higher MSSQL versions
- TFS Control System didn’t feel right compared to SVN and GIT (at least for me).
In the Web Team we decided to migrate only apps to TFS which were not maintained by external suppliers and we decided to use the Source Control from TFS without any other features because we had already other tools and TFS didn’t provide the features we needed. Not the standardization we wanted!
We used TFS for about 2 years before we explored VSTS former Visual Studio Online. We created test accounts and uploaded some of our side projects for testing purpose. From the beginning I was convinced about VSTS. Microsoft supported GIT in TFS (unbelievable). After further tests and some internal discussions about security and other concerns (our code is now in the cloud) we decided to switch from TFS2012 OnPremise to VSTS.
In 2017 I can say that this decision helped us to standardize the development process across all Teams in our department. Now we are more than 20 people.
- Every developer uses the same Source Control System
- All the backlogs for our projects and products are maintained in VSTS.
- We use GIT across all teams.
- Through our MSDN Subscription we don’t have to pay extra for our accounts and external suppliers can be added in minutes to the projects. (If they have MSDN no extra costs)
- Our stakeholders have now one common system when working with different teams together
- We started to introduce SCRUM in some of our development projects which is greatly supported
- We created real CI/CD Pipelines and one click deployments
- We used the possibility to host private NuGet Packages to share libs between the teams.
- It has a great extension system where missing features can be added in seconds
- Every three weeks they release new features, the roadmap is public and you can bring new ideas to the VSTS via UserVoice
- The Pull Request process is better than on GitHub
- It has free tier for small teams
- It provides integrations to other systems like Slack, GitHub or Microsoft Teams
- Seamless integration to Microsoft Azure
- It stands for the new Microsoft! The VSTS development team use it for VSTS development
VSTS offers so many more possibilities which are not mentioned here. It didn’t solve all our problems but it solved many of them. This was only possible due the fact that the system works and it offers all the features which are needed for modern software development.
Recently we had the requirement to change the Urls of some WebServices which were provided by our current WebSite. We do not have a complete reference of all calling applications which are dependent on the WebService. With the VSTS Code search we were able to find all applications which are pointing to the specific address.
The search brought up all files where our domain were used (Screen doesn’t show all results). It was easy for us to identify and change the URLs. This example shows how helpful it is to have everything in one system.
Links:
