Moonbeam: Adobe's Internal Build Queue System
I spent some time this year building better internal tools for the Behance developers— Moonbeam, our internal build queue system, allows developers to safely make updates to the website/service on guardrails. This system eventually will be rolled out to all of Adobe's development teams (more than 5,000 internal users)!
UI/UX design, user flows, wireframes, user research and interviews
Bryan Latten · Project Lead
Jackie Balzer · Engineer
Complete: rolled out to internal employees starting June 2016
USER NEEDS & USER interviews
Previous to this deploy system, developers were not able to build multiple times a day, so it was a mental shift for the team to get used to having a build queue per service, and being able to deploy across multiple services simultaneously. I conducted some user interviews with various developers across the front-end and back-end teams, but the majority of my user research was focused on our QE team, who maintain this service and help facilitate Moonbeam's rollout to other internal teams.
BEHANCE WORK ON THE LANDING PAGE
Not all internal teams in Adobe necessarily know that the Behance development team is the one behind Moonbeam, so I wanted to display some work from Behance that went with the space theme. This layout mirrors my designs on the Behance About page for consistency's sake, but the main call-to-action is to log in. No signup was necessary, as it was only available internally.
SelECTING A SERVICE
Each individual dev had access to specific services, and we needed devs to have a high-level overview over how services were performing, and what they could expect when selecting a service to build to. The page displayed key information at a glance:
- Which services the developer had access to
- Who was currently building to that service (who is in control?)
- Who was waiting to build to that service next
- The number of deploys in the last 24 hours
- And the last deploy to that service
The hover states for this view revealed a user's Slack username and Github profile for easy identification across +5,000 employees.
I also had to account for situations where a developer might have so many different services that there would require some admin-level bucketing of the services to make it easier to navigate.
so you've selected a service...
After a dev has selected the service he/she wants to build to, they land in the service's build queue. The queue shows you who is building before you, who is building right now, and recent builds. The timeline of the build queue moves from the top down.
The biggest CTA here is to "Join the deploy queue" so that you can start building ASAP.
You're queued up
While waiting, you also have the option to jump to the first in queue (for emergency use or to patch something quickly).
YOU'RE IN control!
Once a user is control of the build queue, they can select the pull requests to deploy. There's always an option to relinquish control at any point, if everything is on fire.
Whether or not you're in control, you have the ability to always select different services from the top nav dropdown. If you're in the queue for multiple services, the status of that service will also be visible.
SELECTING YOUR PULL REQUESTS
The page transitions to letting you see what pull requests are open (both by you and by others) and what the statuses for the other PRs are. PR's that require approval will still appear, but they will be unable to be deployed.
You can select multiple pull requests for a single deploy, but only if users have been granted access to that feature by admins. The "Select multiple pull requests" button will display checkmarks for available PR's.
Once you've selected which PR's to deploy, the deployment timeline appears to walk you through deployment. The 4 stages of Build/Dev/Stage/Prod are variable and the stages can be added/removed by admins in the backend.
The checklists assist devs in having access to handy dashboards and other service-specific reminders. Once checkboxes have been checked, a dev can move onto the next step of building.
During a build, the ability to leave control is temporarily greyed out.
Once the dev build is complete, the timeline at the top moves into a success state for that stage, and links for build logs and parameters appear. You can continue through this process until you've reached production.
Once a build is complete, there is a final confirmation popup.