Reinventing processes with BuildMaster, and in turn, finding a critical solution in emerging SharePoint-BuildMaster usage.
When a housing department's development and IT teams discover they had been using sub-optimal build and deployment practices, they used a vendor shake-up as a positive opportunity. They free up some of the team's time, and resources, as well as allow them to look into DevOps; with the aim of correcting the previous build/deploy policies.
Our BuildMaster user at The University of Nebraska-Lincoln (UNL), home of the famed Big Ten football team, the Cornhuskers, is the IT shop within the University Housing department. UNL University Housing houses roughly 6,000 students per year, and has roughly 1,100 employees. University Housing IT is focused on employee needs and residential logistics.
As the team started looking into popular build automation and continuous integration tools, they found many of their concepts were not easy to grasp, and not properly equipped to handle what the team was looking for: a full DevOps including automated release cycles, release planning facilities, and functionality to prevent code from being manually copied from environment to environment.
When the team evaluated BuildMaster, they found that structuring a release, and the functionality/philosophy of building in integration, pushing to test, closing out issues in test, and ultimately pushing to production, BuildMaster just made sense for what they wanted to do.
The SharePoint-BuildMaster Usage
The origins of this use case were somewhat accidental; while working on a build plan for a different application, it was noticed that you could run PowerShell from within BuildMaster, which resulted in finding PowerShell scripts that could be used to install SharePoint applications. The new process is incredibly useful for the UNL housing department's IT team as once the build is kicked off in BuildMaster, BuildMaster then manages the deployment and install process; copying the artifact from the BuildMaster environment up to the SharePoint server, kicking off scripts to install the package, and running it in the background. This process captures the sort of automation BuildMaster is traditionally known for, in a new and exciting case with SharePoint.
The combination of BuildMaster and SharePoint has become more and more popular since 2015. We look forward to seeing more SharePoint users adopting BuildMaster as both BuildMaster, and SharePoint, are growing platforms that more and more teams are using.
From one of the members of the UNL Housing IT team, "We had SharePoint when we purchased BuildMaster, but we were not using it to the extent that we are today. Today, most of our custom applications use SharePoint as the delivery method. So being able to use PowerShell and script deployments into SharePoint from the BuildMaster environment is huge for us. I see the SharePoint deployment method being a huge gain for us as we are able to create a portal-like experience for our users to get all of their data and job functions in a single place."