Deploying Better Build Automation: The 5th Key to Developing a DevOps Culture
Welcome back to the vRad Technology Quest Series. We’ve shared how vRad builds and deploys code (vRad Development Pipeline (#2)). This article is an...
Remote radiologist jobs with flexible schedules, equitable pay, and the most advanced reading platform. Discover teleradiology at vRad.
Radiologist well-being matters. Explore how vRad takes action to prevent burnout with expert-led, confidential support through our partnership with VITAL WorkLife. Helping radiologists thrive.
Visit the vRad Blog for radiologist experiences at vRad, career resources, and more.
vRad provides radiology residents and fellows free radiology education resources for ABR boards, noon lectures, and CME.
Teleradiology services leader since 2001. See how vRad AI is helping deliver faster, higher-quality care for 50,000+ critical patients each year.
Subspecialist care for the women in your community. 48-hour screenings. 1-hour diagnostics. Comprehensive compliance and inspection support.
vRad’s stroke protocol auto-assigns stroke cases to the top of all available radiologists’ worklists, with requirements to be read next.
vRad’s unique teleradiology workflow for trauma studies delivers consistently fast turnaround times—even during periods of high volume.
vRad’s Operations Center is the central hub that ensures imaging studies and communications are handled efficiently and swiftly.
vRad is delivering faster radiology turnaround times for 40,000+ critical patients annually, using four unique strategies, including AI.
vRad is developing and using AI to improve radiology quality assurance and reduce medical malpractice risk.
Now you can power your practice with the same fully integrated technology and support ecosystem we use. The vRad Platform.
Since developing and launching our first model in 2015, vRad has been at the forefront of AI in radiology.
Since 2010, vRad Radiology Education has provided high-quality radiology CME. Open to all radiologists, these 15-minute online modules are a convenient way to stay up to date on practical radiology topics.
Join vRad’s annual spring CME conference featuring top speakers and practical radiology topics.
vRad provides radiology residents and fellows free radiology education resources for ABR boards, noon lectures, and CME.
Academically oriented radiologists love practicing at vRad too. Check out the research published by vRad radiologists and team members.
Learn how vRad revolutionized radiology and has been at the forefront of innovation since 2001.
Visit the vRad blog for radiologist experiences at vRad, career resources, and more.
Explore our practice’s reading platform, breast imaging program, AI, and more. Plus, hear from vRad radiologists about what it’s like to practice at vRad.
Ready to be part of something meaningful? Explore team member careers at vRad.
5 min read
Brian (Bobby) Baker
:
April 5, 2017
Welcome back to the vRad Technology Quest.
At vRad, we value our ability to deliver frequent, regular, and minimally interruptive releases and today I’ll provide an overview of the development pipeline we utilize to achieve those releases.
What is a development pipeline? The development pipeline is the chain of tools and processes that we utilize to take the code from a developer’s laptop, get it ready for prime-time, and ship it to production. Our development pipeline is a large part of the overall Software Development Life Cycle at vRad.
![]() |
Software Development Life Cycle refers to the overall set of tasks for building, testing, deploying, and maintaining software. |
If you are familiar with development pipelines you may have heard terms like “continuous integration”, “continuous deployment”, “continuous release”, and other phrases using the term “continuous”. Like other companies and teams, we place a high value on the “continuous” aspect of development – we often think of the pipeline as a conveyor belt in a factory – keeping it moving and on schedule is critical.
Our preferred term for our development pipeline is “Continuous Test” because testing is our primary focus through the pipeline.
![]() |
Continuous Test refers to a model of running tests on a continual basis to ensure quality. |
vRad’s end goal in software development is to release high quality features to production in an efficient way. Our automation focus within the pipeline isn’t centered on releasing to production, but instead on constantly testing our changes. Our pipeline is inspired by other “continuous” pipeline models from other large-scale platforms including Etsy (https://codeascraft.com/2012/02/13/the-etsy-way/) and Netflix (http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html).
Some steps we’ll explore here might not seem like traditional “tests”, but at vRad, our teams view the entire process as testing for production. This includes compiling the code, packaging the code, deploying the code, running automated tests, running manual validations, and over 75 other checklist items that make up an iteration of our SDLC (Software Development Life Cycle).
The below infographic illustrates the various branches of our pipeline – many of these steps are run in parallel with each other; we’ll talk about each type of test below.
Before diving into the details of individual test steps, I want to share a bit about the culture within the vRad engineering department.
When developing software, the starting point is a developer sitting at her computer; we believe that each developer should be empowered to run as much of the full pipeline from her computer as possible – or “locally” as we call it. We have over 100 different modules across 3 subsystems which are worked on by a mixture of our product teams. Each developer has the tooling and basic understanding to not only compile all of our applications, but the knowhow to perform a full packaging of our products, full deployment of all of our modules, and run our thousands of automated tests – all right from her laptop.
Once she checks the code into our source code repository, our Build Server (Atlassian Bamboo and BuildGuru) initiates a host of automated continual tests on our test infrastructure. Our testing infrastructure will notify a developer if she breaks any tests.
*Stay tuned for more on our Build Server in vRad’s Build Tools (#5) and our test infrastructure in vRad Test Environments (#3) and vRad Automated Testing (#4)*
While breaking a test will result in a high priority to fix the test, test breakage is not considered a bad thing. We encourage developers to make changes that move our platform forward – our pipeline is designed to catch the mistakes so developers don’t have to use a “fear driven development” methodology.
One of the first set of tests in our pipeline are build tests.
![]() |
Build tests verify that code can be successfully compiled and packaged for deployment. |
An important part of the philosophy at vRad is to “build everything”. This means that each check-in triggers an entire system build – over 100 modules are built. The build takes approximately 20 minutes and results in a package that contains all 3 of our subsystems in full – over 5 GB of packaged software. This philosophy ensures that we always have the latest build of every module of our systems –changes are flushed through the system quickly and efficiently.
I’ll share more about our build tools in an upcoming article – stay tuned for vRad’s Build Tools (#5); one of the key aspects of our entire development pipeline is performance. Because we run all of these test steps continually, it’s important for engineers to get feedback right away. Compiling our entire platform used to take over 2 hours; we recognized this as a bottleneck and have reduced it to about 20 minutes over the last few years (to be specific, a raw compile of our platform takes only a few minutes and is done as a specific test step, the 20 minutes is a full package of the platform, which involves writing the applications and components in a particular way into a package to be deployed during later steps).
Once packaging is verified, we move to deployment tests to verify that we can successfully deploy the software.
Every hour we produce a new package from our “build test” and that package is immediately tested for deployment. The deployment utilizes the same metadata driven toolkit that the package is produced from, which helps simplify the system’s knowledge of the applications themselves.
vRad application deployment comes in various shapes and sizes – web applications, Microsoft ClickOnce based Windows applications, Windows service applications, SQL modules, and various others; each module has quite a bit of metadata including security information, configuration information, and about 15 other attributes, so having our builds and deployments from the same toolkit enables a lot of flexibility around all this metadata.
Once a build is packaged and deployed, that build is promoted for usage in other environments. This idea of ‘promotion’ is important for our pipeline because different environments can tolerate different levels of code. In a typical development phase, for example, it is acceptable for our package to transit through builds, deployments, and hours of various automated tests prior to being available (promoted) for usage by another environment. On the other hand, if a flaw is discovered at 2am and needs an immediate resolution, we can quickly build a single application and run a limited set of tests prior to releasing to a test environment – we build in the flexibility of skipping some of the promotion steps for urgent situations.
While application deployments have pretty robust tooling and rely primarily on “file copy” technology, SQL deployments are a bit more complicated. For SQL Deployments, we check all of our SQL code into our source code repository in an idempotent fashion: meaning the SQL can be run repeatedly without error. For SQL deployments, we deploy all the idempotent SQL for a database.
Early on, we found that around 75% of our deployment failures were SQL related. To correct this, we added a parallel process step to help catch SQL related failures earlier on. While packaging is going on, we test deploying SQL to a DB only environment so that SQL failures provide feedback within 5 minutes instead of within 25 minutes (when waiting for packaging to complete).
We have thousands of NUnit tests built into our code base. These test are built, packaged, and deployed in a similar way to our applications. A full package of our software includes the tests themselves.
Typically, the term “unit test” implies a fast, “code only” test that is small (thus the term “unit”). At vRad, we test in layers: our unit tests are comprised of traditional code-only unit tests, as well as NUnit driven tests that test the code and database layers. For automation purposes, we treat these two types of tests the same and refer to them as unit tests.
To run these tests, we deploy them to clients and execute them remotely, then collect and display the results in Bamboo. Any failures are then triaged by the developers associated with the changes.
Finally, we also have automated UI tests using the Ranorex product. We have thousands of test cases built into our UI Test Suites and we execute them similarly to our unit tests – we deploy and execute them remotely.
Our Ranorex tests utilize a Page-Object design pattern that we’ve found to be incredibly robust. We spend very little time triaging these tests and their success rate surpassed our expectations. When failures do occur, we have a small team of Ranorex developers who own triage to determine if the script failed or if the failure was a genuine bug in the software.
Our development pipeline is designed to continually test the vRad platform. Each change to our code base triggers half a dozen different test paths incorporating thousands of automated tests. This enables us to deliver features faster and with higher quality.
I hope you enjoyed this look into the vRad approach to building code; stay tuned for our next article on vRad Test Environments (#3). And remember, we’ll be tracking all 7 keys to unlocking a DevOps Culture, as they’re released, in the vRad Technology Quest Log.
Until our next adventure,
Brian (Bobby) Baker
Welcome back to the vRad Technology Quest Series. We’ve shared how vRad builds and deploys code (vRad Development Pipeline (#2)). This article is an...
Today in the vRad technology quest we set forth to understand Dev (or test) Environments. Let’s jump right in.
At vRad, we have a passion for connecting – with each other, with clients, and with patients. In technology, we strive to break down the language...
vRad (Virtual Radiologic) is a national radiology practice combining clinical excellence with cutting-edge technology development. Each year, we bring exceptional radiology care to millions of patients and empower healthcare providers with technology-driven solutions.
Non-Clinical Inquiries (Total Free):
800.737.0610
Outside U.S.:
011.1.952.595.1111
3600 Minnesota Drive, Suite 800
Edina, MN 55435