OTHER CASE STUDIES:
The University of Nebraska-Lincoln (UNL)
The University of Nebraska-Lincoln (UNL), home of the famed Big Ten football team, the Cornhuskers, is Nebraska’s oldest and largest university in the state university system.
UNL’s use of BuildMaster has saved many work hours, reduced the concern of risk associated with manual builds and deployments, and overall has led to greater confidence in making more frequent changes.
Our BuildMaster user at UNL 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.
The Challenge:
A vendor shake-up, wherein a legacy mission-critical vendor solution related to storing University Housing management records was replaced for another, exposed the fact that UNL’s housing department’s development and IT team(s) had been using sub-optimal build and deployment practices during the time period in which they painstakingly maintained the previous vendor solution. The “shake-up”” proved to be a smart move as it freed up some of the team’s time/resources, as well as allowed them to look into DevOps; with the aim of correcting previous build/deploy policies.
Looking into tooling, the team started with evaluations of popular build automation and continuous integration tools including Jenkins and Team City. In regards to said evaluations of those tools, Ross Louch, Assistant Director of Technical Solutions, commented “something seemed off; their concepts were not as easy to grasp (in so much as they are known to be fairly simple tools) and not properly equipped to handle what the team was looking for: a full DevOps suite including automated release cycles, release planning facilities, and functionality to prevent code from being manually copied from environment to environment.”
The team proceeded to evaluate BuildMaster and according to Louch, “In terms of structuring a release, and with functionality/a philosophy of building in integration, pushing to test, closing out issues in test and ultimately pushing to production, BuildMaster just made sense for what we wanted to do.”
The Solution:
As with most BuildMaster users, the automation and planning aspect of the tool has led to many work hours saved, reduced concern for risk/errors that come with manual builds and deployments, and has led to greater confidence in making more frequent changes.
It can be said that the usage of BuildMaster has ushered in a new era for UNL’s housing department’s IT team. In fact, as usage of Microsoft’s SharePoint has increased drastically over the past few years within the department; with up to 90% of the department’s internal development written into SharePoint web-parts, the IT team has found an interesting case of using BuildMaster to deploy these SharePoint web-parts into an internal SharePoint environment.
Previously, manually migrating a web-part into SharePoint was a time consuming, laborious process. The old process can be done in PowerShell but necessitates many commands/actions, and is ultimately a bit of a headache. As a result, finding this new solution with BuildMaster has been very beneficial according to Louch. The origins of this use case were somewhat accidental; while working on a build plan for a different application, Louch noticed that he 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.
Overall Results:
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.
In terms of the results, Ross Louch had a few remarks:
“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.”
