Enabling Skylight in Multiple Environments Just Got A Whole Lot Easier!
Skylight’s new Environments feature allows users to easily enable Skylight’s smart performance profiling in multiple environments and effortlessly navigate between an app’s environments in the Skylight UI. Now available with the 3.0.0 agent.
By default, the Skylight agent only enables itself in the
production environment. In many cases, your applications will have other environments that you would like to profile using Skylight. For example, Rails ships with
test environments by default. You can also create additional Rails environments, such as
While enabling Skylight in multiple environments has been possible for a while now, we have recently invested significant energy in streamlining the process and improving the user experience:
- All environments use a single authentication token!
- All environments share a single collaborators list!
- Environments are grouped together in Skylight’s UI, making it easy to compare them.
- The Skylight agent automagically detects which environment it is running in!
- Only the production environment is displayed in Trends emails, making it easier to find the updates that matter to you!
Previously, to set up a second environment, users created a second “app” in Skylight. In reality, the second “app” was just the same codebase in a different environment. Now, Skylight will allow you to toggle between your environments within the same Skylight “app.” In our internals, each environment is a “component” of your app on Skylight. To enable Skylight in an additional environment, all you need to do is flip a switch!
I’m sold! How do I turn it on?
What if I already have multiple environments set up in Skylight using the old method?
You aren’t alone! During the planning of this feature, we estimated that about 10% of Skylight “apps” are actually environments for other apps! Wow! 😲
Previously, users needed to manually create a separate app and set an authentication token per environment. Because this was sort of a workaround, it meant that users with multiple environments had to manage multiple authentication tokens and collaborator’s lists. No more!
Because we have no way of knowing which of your current apps should actually be environments, we assumed that all current apps represent “production” environments. In the meantime, we did our best to identify apps that should probably be migrated (e.g. if they contain “Staging” or “QA” in the app name) and notify those apps’ collaborators. App owners can “merge” these legacy environment apps into their parent app (the production environment app) following a simple command-line interface (CLI).
Once you merge your environments into the parent app, all environments will use the same authentication token and collaboration settings.
What if I have MULTIPLE staging environments?
Your Skylight environment name can differ from your Rails environment. For example, many
staging servers are actually running the
production environment. Or, you might have multiple staging servers running different versions of your app, so you want to see the Skylight data for them separately:
staging-2, etc. Because Skylight relies heavily on request aggregation, we recommend that all servers running the same version of your app be given the same environment name.
How the heck did you implement this shenanigans?
Zach is our newest Tildeño, so naturally the best on-boarding project was a highly complex refactor of existing code that touches All The Things: inserting the concept of an “App Component” (with an associated environment) between the “App” model and the data in the collector. At first, we deployed the code with a simple migration that generated one “App Component” for each “App.” If we did our job right, you didn’t even notice this change. 😎
Then began the heavy lifting. We wrote/changed a ton of code in both our Rails and Ember apps allowing apps to have multiple components, users to toggle between them, and data for multiple components to be grouped by app (e.g. for billing). Given that the “App” model is central to pretty much every process in our ecosystem, this was no easy task.
The changes in the agent were the simplest, since all the agent really needs to do is detect the Rails environment (or the
SKYLIGHT_ENVIRONMENT environment variable if you want to customize the environment name) and report that information when it authenticates to report data to our collector. We also added a CLI to the agent to facilitate the migration to the new feature for users who already have environments set up the old way.
One of the biggest challenges was providing a smooth upgrade path from separate apps to apps grouped by app component (environments), while maintaining continuity for data collection, while ALSO being able to support the ORIGINAL authentication scheme (i.e. with separate tokens for each app) as well as the NEW authentication scheme (which will allow you to share authentication tokens between components). Phew!
Once all of the above was substantially completed, we started a beta program with our Skylight Insiders users. Skylight Insiders get access to beta features before we release them into the wild. You, too, can join the Insiders program! Click here to learn how. Thanks so much to our Insiders who tried the new feature, gave us feedback, and reported bugs!
We’ve gotten many feature requests for background jobs instrumentation, but we’ve been blocked on the major user interface changes required for such a feature. Implementing the Environments feature allowed us to do much of the heavy lifting for the background jobs feature UI. The “App Components” work we did for Environments will make it easier to implement background jobs; jobs will just be another “Component” of the same “App.”
Credits (in order of appearance)
Initial Head-scratching and Architecturing: Godfrey and Krystan
Database and Rails App OMG: Zach and Krystan
User Interface Rejiggering: Krystan
Agent Updates: Zach and Peter
Command-line Interface: Zach and Krystan
Documentation and Bloggering: Krystan
Dogfooding and Bug-finding: Lee