Datastream Connexion has been with us since the beginning. They have seen BuildMaster as it has grown over the years. More than that they have given us insight and suggestions that have had a definite impact on BuildMaster’s development. Their work, both within a technical sense, and in the context of the government contracts behind it, is a great example of the flexibility of BuildMaster. They were kind enough to give us a look into how BuildMaster works for them.

---

Tell us about Datastream Connexion:

We are custom application builders focused on large collaborative solutions for the federal government. Since 2004 we’ve been building a secure infrastructure protecting the nation’s food supply from contamination or deliberate attack called FoodSHIELD.

FoodSHIELD remains an important project for us while we work on others such as coreSHIELD, a secure web-based infrastructure to enable information exchange amongst our nation’s critical infrastructures, PETNet, a secure reporting/notification system, accessible by state and federal government officials with regulatory authority and responsibility over pet food, and Food Emergency Response Network, a secure collaboration and reporting portal to support the national food emergency response laboratories.

You’ve been using BuildMaster since the very beginning with version 1.2. We just released 3.5 this week. As a user, do you have any comment on the evolution of the software?

Wow! Great! The BuildMaster users at OE Connection mentioned something very similar.

We view the use of BuildMaster as a part of our strategy and its use has only increased through time.

I was recently brought on as a CIO of another healthcare company in town, and we want to use a similar deployment methodology as we have with Datastream Connexion. We want BuildMaster to continue to play an important role and as that firm uses Podio to essentially manage its operations and developments, we’re working with your team on some customizations right now. BuildMaster is the tool we want working side by side with Podio so we can assure that the development lifecycle loop is complete and everything we do is sorted and well thought-out.

BuildMaster is a strategic differentiator for us. It’s something we use when we talk to clients about how we handle deployments and manage our integrations.

This provides great peace of mind to our federal clients; they really like that we don’t have to do everything continuously and integrate it all at one time, but can build individual portals and applications with BuildMaster. That infinite flexibility has greatly served us.

“BuildMaster is a strategic differentiator for us. It’s something we use when we talk to clients about how we handle deployments and manage our integrations.”

ACan you give me an overview of how you developed software before BuildMaster?AA

Before BuildMaster it was very different. We played with Ant and hooks and basically were doing FTP transfers, manual database updates. We were manually trying to migrate the same application across 15 portals. The whole thing was fraught with errors. We’d miss a file here, an ftp there. It was really difficult to generate a good audit log of what happened where and when. So we were frequently ending up with issues on builds that weren’t necessary. Our primary problem was that we couldn’t reliably deploy our software and needed a solution for that.

What lead to you considering BuildMaster?

As we exist in a web environment, we were looking for tools that would support the very unique requirements that we have as well as allow us the flexibility we need. One of the priorities was to make sure we had a hosted environment for our compliance requirements and that we were able to maintain the application between our FISMA compliant firewalls. With that said, we didn’t want to use an external product.

We looked into Beanstalk and Thoughtworks. It was very tough for us; we felt we had some real challenges with our releases and needed support getting through it as well as a tool that could be as flexible as we are but solutions weren’t being readily made available by other firms out there. Luckily, the consulting arm behind Inedo really helped us drill down what we were trying to accomplish. That really made BuildMaster attractive to us and why we’ve continued to evangelize it.

You’ve mentioned special requirements and compliance a few times. What sort of special requirements do you have working with Federal, state, and local governments as you do?

We’re a FISMA Moderate shop which means we have to maintain control over our code. It’s not a very good idea to throw code in a system meant for homeland security on the cloud so having an on-premise solution we’re able to leverage that still has support behind it is critical for our success. That support arm is very important compliance-wise.

I’d imagine these types of requirements and compliances are common for a number of other BuildMaster users, folks that have sensitive IP or intellectual property needs.

With a number of the other deployment software vendors out there you have to throw your code on the cloud and push it around. Our attorney’s weren’t very pleased with the idea of doing that.

Were there any specific features about BuildMaster that lead to your adopting it?

Specifically we liked the extension libraries and the ability to plug into many different things. We liked the ability to micro-manage deployments and have deep control of what went where, why, and how, especially because each of our projects have specifically different requirements. We could either manage deployments or we could turn to continuous integration. Those were the 3-4 big things we could allow ourselves to have the flexibility to operate how we wanted.

We pride ourselves on integrating with a number of best-of-breed tools so our users can adopt BuildMaster with their existing toolsets. Can you tell me what tools you already used?

One of the things that was important to us was that you supported Seapine. We use Seapine’s software suite because their easy to reporting is good for our compliance requirements. That we were able to basically integrate with everything and not change a thing was really critical. I didn’t want to get into the world of changing tools and servers. Putting BuildMaster on the servers was very low cost and very easy so it was basically plug and play with the agents, so off we went.

“Putting BuildMaster on the servers was very low cost and very easy so it was basically plug and play with the agents, so off we went.”

How has your team used BuildMaster?

Mostly, we have formalized our release processes but of course, that was a multi-faceted project in itself. We’ve used BuildMaster as a benchmark for our releases and our ability to accurately report on a release and what was released per portal. Working with BuildMaster means we have a core piece of software that we can customize for every client; a core piece with 15-20 different iterations that can possibly go out the door.

We spend a lot of time in BuildMaster making core applications and building workflows around the other portals. A big part of that is making sure we can grab the right code from very discreet places in Seapine’s Surround as opposed to taking a global approach where we have take all the code. The ability to drill down and take specific pieces of code with BuildMaster is very cool. It helps us do our deployments very simply to different customized posts.

What benefits did working with BuildMaster ensure for end-users?

I think the biggest thing is enjoying stability. We’re an agile shop. We do major deployments every sprint cycle but we are continuously building small bug fixes all week long as they’re found, so we build quite often. The granular control within BuildMaster that allows us to target certain portals overall means a lot more stability for our end-users. They definitely appreciate the fact that we’re able to do these deployments in a stable way instead of doing the typical 9 month cycle that other shops have to employ.

Regulated control is also a significant benefit. Clients and end-users know that change controls are signed off on. That we can follow the processes that are required by the clients and document them as well as the releases very simply is real big thing to them. BuildMaster isn’t “the wizard behind the curtain,” it makes our work transparent and explainable.

How many are affected by this with something like the Food Shield program?

Of course it’s only our team that’s actually logging in and using BuildMaster directly but teams over at the USDA and FDA, as well as state and local governments are receiving reports we’re generating from BuildMaster, so I’d say several thousand. With that said, what’s better for us is better for them, ultimately.

In the past there was a lot of mystery around the what, where, when, and why in terms of releases and this gives us transparency. Part of federal requirement for monitoring systems is knowing what happened and why. We knew what we were doing before but now we’re able to show a nice report that provides all sorts of different information. For instance, if we want to show what code changed from one release to the next, or different groups have different requirements, we can show any or all of that pretty specifically in a report.

“The reports BuildMaster can generate very clearly illustrate that we have done our job, how, when, where, and why.”

What’s also great for us is that this ability to report so specifically is a very handy tool when it comes time to renew a contract. Program managers on the client side are looking for is to see contracts have been satisfied, that we have met the “spirit of the need” for which we were employed. The reports BuildMaster can generate very clearly illustrate that we have done our job, how, when, where, and why.

Has using BuildMaster lead to any notable changes in culture?

It’s lead to some surprising changes amongst our developers. Before BuildMaster nobody could agree on a process and it was a little like the Wild West in our dev department. What we found was that people modified their expectations and development patterns to mimic and mirror a successful BuildMaster approach. Using BuildMaster brought structure back to the development team and lead to both more cohesion and critical thought around how we can deploy, or how to do change scripts. It really was impressive to me that folks were able to rally around a single point, focus on how to do their jobs better and make sure deployments work well… and that was really not expected.

The developers go and look at the releases each week and see what portal got what and it provides a bit of a security blanket for them. They feel better knowing BuildMaster’s been run as well as knowing what’s been run in it.

“Using BuildMaster brought structrue back to the development team.”

Do you have advice for others considering BuildMaster?

You think you know what your capabilities are as a group, but until you get BuildMaster fired up and under the hood you don’t realize what all it can do for you as an organization. That matters because I think people go into evaluating BuildMaster with the standard expectations of a build tool and expect some simple behaviors based on past experiences.

However, if you go in willing to re-think your processes, that’s going to be both the biggest game changer and bang for your buck. BuildMaster will pay for itself many times over just by opening your organization up to the new possibilities for running your releases.

“BuildMaster will pay for itself many times over.”

Thank you very much. Would you recommend BuildMaster to others?