As discussed in a previous post, disaster can strike at anytime. Most companies think about things such as protecting documents, insurance for property, fire safety procedures, and other physical protections. But what do you do about software assets. Does your company create software? Even non-software companies often create software. In-house IT departments will often have utilities and other little bits of code that are really useful in keeping a company operating smoothly and most employees and executives of the company may not even know its being used.
When Disaster Strikes
My company develops software for ourselves (Windows Store) and for our customers. Microsoft’s partner program is flexible enough for not only larger Fortune 500 companies to partner with them but also small software consulting firms like ours and everybody can win. One of the great features of the partner program for us is our Microsoft Action Pack Subscription that provides us countless benefits but the one I want to focus on today is the Visual Studio Team Services (VSTS) account.
Let me go back a bit in time to October 2013 when a fire broke out in the same city block as our office. The fire was devastating, wiping out half of a city block with buildings dating back as far as 1909. I was told by some of the firefighters that the temperature at the heart of the blaze was almost 2,700 degrees (does it really matter if it’s Celsius or Fahrenheit?) and steel light poles across the street were melted. Our building, housing our primary offices, were just one building and a good strong wind away from being destroyed. There was nothing we could do about it at the time… There was, however, something we could do in advance and we did it, have you?
Peace of Mind and Better Software
First and foremost, as stated previously, was the fact that our vast investment in software development was 100% protected in VSTS, either in Git or Team Foundation Version Control. A lot of our legacy software was developed using Visual SourceSafe (VSS) which was migrated to Team Foundation Server (TFS) (on-premise) and then up into the cloud with Team Foundation Version Control (TFVC). If you have any combination of Source Control that uses VSS or TFS then migration is pretty painless. We did it in a day (for four developers). However, newer product development is now taking advantage of Microsoft’s implementation of Git source control. Did you know you can run both simultaneously? Git provides a robust team environment for development, when implemented properly and with reasonable processes adhered to by developers.
Of course, just storing your source code in the cloud isn’t going to get you better software. It might save your existing software or allow your development team to work remotely should inconveniences occur like a power outage at the office or hardware failure for some reason, but you need tools to help with your process to really make gains in quality that go beyond just hiring great developers.
In my opinion the two best features that improved our software quality and the speed of software delivery are the integrated Testing Tools and Continuous Integration. Of course, there are lots of other great features including Agile Tools, integrated DevOps and lots more.
Test, Test and Test Again
Quality starts at the beginning and begins with the developer. However, how do you know that your software is solid. One of the things we teach is to develop unit and UX testing at the same time as the actual software development. No commits without at least a corresponding unit test being included, which sometimes takes quite a bit of willpower. That’s great for the developer testing his stuff but how do you know the quality of a commit into your system. Easy, with VSTS I setup my commit process to force a rerun of all tests when a commit is made on a branch before a Pull Request can be created to merge that branch into the parent. This essentially puts a double check in place that the code created was of high quality. Of course, this is dependent on the developers creating the tests in the first place, so test creating must become part of your culture of development. If I’m creating websites, I can also implement load testing. Having those tests run in VSTS is just one part of Continuous Integration (CI) that you really want to investigate thoroughly.
Round and Round We Go
Continuous Integration is part of combination of a whole host of tools available to the developer and to the process of software delivery. You can have build agents in the cloud automatically build your application with new commits. Results are provided in an extensive report that tells you if anything went wrong, what work items are included and any code changes and test results you may have.
I had the opportunity to work with some students on a team project. The Continuous Integration allowed the team to commit bug fixes and new features without worrying about breaking the master build. No Pull Requests into the dev or master branch were permitted without a new build being completed successfully. CI did the work automatically. Nobody had to “remember” to get it done. On top of the build, CI also executed and reported on all the tests in the software so full regression testing of every committed bit of code was done.
Once all the tests were passed and a Pull Request was completed into the dev branch, CI automatically published the app for our dev team to try out and then when it was rolled to the “staging” branch it rolled out to our customer for review, again automatically, providing very fast turnaround for updates.
We have a pulse
This has all been a great benefit of our partnership with Microsoft. We are able to deliver higher quality software with less work. Continuous Integration along with writing and adding tests to our solutions as we go has created an environment where we can deliver great software. Moreover, with cloud based source control all integrated together we are relatively well inoculated against disaster or just annoying inconvenience.
No comments:
Post a Comment