Auth0 is continuously growing. To share a couple of examples, we just hit a new milestone: [_2.5B+ monthly logins securely authenticated_](https://twitter.com/auth0/status/1101216297206059009) and we [_ended 2018 with a nearly 80 percent increase in both sales and new customers_](https://auth0.com/blog/auth0-closes-year-of-impressive-growth-in-2018/). We are growing and scaling the organization at a really fast pace, and engineering is no exception. This presents some interesting and fun challenges: 1. Promoting and developing the **culture** that fuels this endeavor. 2. **Hiring** and retaining great engineers. 3. Minimizing duplicate work and time to be **productive** as new people come in. This blog post is focused on how Auth0 is addressing part of that last challenge; by building a dedicated team to unleash the potential in Auth0 developers to deliver business value with confidence. ## Developer Tools Team at Auth0 In the same way that Auth0's goal is to make identity simple for developers, the Developer Tools team goal is to let our engineers fully focus on development and providing value for our customers. We want to provide the best tools to keep our developers happy and engaged shipping new features instead of struggling every day with exhausting and repetitive tasks that could be automated. We defined the mindset we want to adopt to develop our tools and outlined a roadmap with the following vision: > Provide toolchains that Auth0 engineering teams can use to improve their workflow, automate manual tasks, simplify complex processes, and implement a set of company-wide standards. ### What we do 1. Work closely with the engineering teams to understand their pain points, provide tools and guidance. 2. Investigate existing tools and develop new ones to solve their needs: * Development Environment tools. * Change Management tools. * Debugging and Performance tools. * Incident Response tools. * Work with the [_SRE team_](https://auth0.com/blog/progressive-service-architecture-at-auth0/) to integrate site reliability tools into the platform. 1. Recommended patterns & practices: * Identify patterns currently in use across our organization. * Provide developer tools for Scaffolding and Code Snippets. * Promote the adoption and tooling for the best engineering practices, e.g.: [_contract testing_](https://martinfowler.com/bliki/ContractTest.html). ### What we don’t do 1. While we provide general guidance, we don’t do consultancy, i.e.: we neither do work at a particular team's requests to tackle specific issues, provide advice on demand, or do an investigation by request nor develop customized solutions to solve a specific team's needs. 2. We don’t provide advice or work on particular issues on demand: our tools are developed following a *product* approach. 3. We don’t embed team members on another team to build tooling. We might do it for discovery, but development happens within the Development Tools team. 4. We don’t debug and profile internal services, we provide the toolchain for that. 5. We don’t do [_SRE (Site Reliability Engineering)_](https://auth0.com/blog/progressive-service-architecture-at-auth0/), we might provide tooling that could improve the experience during their analysis. 6. We don’t investigate a random tool or technology on demand. We do it if it is related to reducing developer pain. ## Tools Development Mindset We are approaching the development of the tools as internal **products**, guided by these principles: 1. **Ownership**: We own the tools that we ship, following a “*You Build It, You Run It*” principle. * We operate what we build: taking care of the CI/CD, incident response, etc. * We take care of not just the coding but also keeping the *product* running in good shape. 1. **Extensibility**: We develop these tools taking extensibility into account from scratch. * For example, any engineer should be able to easily extend* *the* CLI *that we provide to interact with Auth0’s local development environment. 1. **Internal Collaboration**: We engage our users to **contribute** with the tool evolution, collecting their feedback and welcoming their contributions to the code and documentation (via pull requests on git repositories). We aim to follow an **iterative** process to develop our tools (just like our Product Engineering teams), working closely with our internal customers. > The process adopted by our team suits the lean startup cycle model. ->![Jeff Patton & Associates: lean startup cycle model](https://images.ctfassets.net/23aumh6u8s0i/4TRZnZXwjpgNp5gtf4u168/b8ab189eea4a634cdbadfcf67b5c12be/lean-startup-model)<- *[*_Lean Startup Model_*](https://www.jpattonassociates.com/common-agile-int-for-startups/lean-startup-model/)* by *[*_Jeff Patton_*](https://www.jpattonassociates.com/) is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/).* ## Our Tools Some of the tools that we currently maintain and regularly work on had a great impact and adoption rates within the organization but were built prior to adopting the _internal dev tools as product_ mindset mentioned above. It was originally hard for us to *learn *from the tools once released without any kind of usage metrics. For that reason, we focused on existing solutions by: * Improving **documentation**, both user guides and internal playbooks concisely describing deployment, troubleshooting, and **contribution** guidelines. * Instrumenting **usage and performance** metrics to **measure** the impact of our iterative improvements. ### Vivaldi ->![Containers on a dock](https://images.ctfassets.net/23aumh6u8s0i/5d1b2HI9Jjwld4HEksBQff/ec3bdb6bf8883d78cf39f907bb6f65bf/containers-on-a-dock)<- *Photo by *[*_Guillaume Bolduc_*](https://unsplash.com/photos/uBe2mknURG4)* on *[*_Unsplash_*](https://unsplash.com/)*.* **Vivaldi** is the tool on which we have invested most of our efforts so far. Named after the Italian musical composer, it is a [_Docker_](https://www.docker.com/) container-based development environment that allows engineers to run a local Auth0 on their machine. Through a command line interface (CLI), Vivaldi provides commands to quickly interact with our service instances running locally in order to: * Update dependencies. * Run tests. * Attach a debugger. * Run diagnosis tools. * Execute performance profilers. ->![Vivaldi: Docker container-based development environment](https://images.ctfassets.net/23aumh6u8s0i/1NlLXfq8I0vpBm5KL3cI5l/30cd621072a76bcd0406151786f49246/vivaldi)<- The initial version of the tool had a **great impact on the development cycle** and was **widely adopted**. Before *Vivaldi*, developers needed to manually spin up the services they were working on, fighting with dependencies with their local environment. Now they can rely on an isolated and replicable environment, being able to spin up the entire services cluster relatively quickly. As our teams and number of services grow, we are now actively working with teams to better implement a fast development loop without relying too much on running all Auth0 services locally. We are already planning the next generation of Vivaldi, which will support future growth in a scalable way. ### Slack Bots ->![Droid giving you a helping hand](https://images.ctfassets.net/23aumh6u8s0i/H5W70I4X8Ot6NSsj0VHyv/fadc300cf5495e31413a4ef43f2128d7/droid-giving-you-a-helping-hand)<- *Photo by *[*_Franck V._*](https://unsplash.com/photos/jIBMSMs4_kA)* on *[*_Unsplash_*](https://unsplash.com/)*.* We developed an internal Slack bot platform called _Gynoid_ during a hackathon and it was quickly adopted by our engineering organization. The platform is customized to satisfy the needs of our developers: * To build Slack bots easily: just create a JavaScript file, add metadata, and you are done!. * To install Slack bots straight from a GitHub repository. * To extend existing bots from different sources: one bot, multiple functions, different repositories. * We call these extensions Droids. To install new extensions, we have a Gynoid that serves as a wrapper for this library. Our _Gynoid Droid_ is responsible for registering and extending our bots directly from Slack. A notable Droid is one that serves as a _concierge_ for any Slack channel, properly named @concierge. It works like this: * A channel that needs a person on duty to address direct questions invites `@concierge` to the channel. ->![Inviting the concierge Slack bot to a channel](https://images.ctfassets.net/23aumh6u8s0i/762YoyCbXhOlyM9zQAr24/469fe557035293e641012aa2bc03c672/invite-concierge-slack-bot)<- * A teammate is assigned the role of `@concierge`. ->![Assigning the concierge role to a teammate](https://images.ctfassets.net/23aumh6u8s0i/2u1bJjRFdCbJWf48k9t1Ot/3fb1c5c67e6d6819df21f09564896e18/assign-concierge-slack-bot)<- * When someone needs to ask anything to a team, for example, they visit the team's channel and ask the question directly to `@concierge`. ->![Asking a question to Slack bot concierge](https://images.ctfassets.net/23aumh6u8s0i/3Gtm4wdoomqbMJas4rzjGf/a1249a2842972eae97cc08b29328a28d/asking-question-concierge)<- * The teammate with the role of `@concierge` is sent a direct message through Slackbot with the concierge request. ->![Slack bot concierge sending a direct message to teammate](https://images.ctfassets.net/23aumh6u8s0i/4nPgWa3KasUha1YjLcAmos/641263ac54adb338d5906ee7d410673b/concierge-slack-bot-direct-message)<- * The concierge has now the responsibility to research and to address the request directly. If the request is outside of the scope of the team, the request is redirected to the appropriate channel The concierge droid helps us avoid unnecessary noise in Slack — especially since it is widely used within our company as a good substitute for `@here` and `@channel` when asking questions. It's very useful when you have an "on-call" rotation in your team and people need to reach the teammate on call through a Slack channel. ## Roadmap We are currently working on the next major version of our main tools, focusing on: * **Scalability improvements**: Vivaldi, our Docker-based development environment, will run an increasing number of services without compromising the developer machine resources. * **Robustness**: Gynoid, our slack bots platform, will have end-to-end tests and its dependencies will be upgraded to the latest stable versions, allowing our team and contributors from other teams to introduce changes or develop new *droids* with confidence. Additionally, we’re in the early stages (discovery, viability analysis, and ideation) for a **unified internal CLI** (command-line interface): we already have multiple CLIs that provide different types of functionality. As the number of CLIs keeps growing, it will become hard to keep track of them. Some teams will decide to use a different tech stack, which may require different runtime dependencies and a distinct CLI to better manage it. However, we could create a unified CLI, customizable and extensible to meet the needs of different tech stacks. Having a unified CLI will help internal toolchains scale while staying maintainable. ## Conclusion We aim to provide an optimal developer experience, unified across the engineering organization. To do this we take ownership of the toolchains, iterate to improve them and encourage teams to use these tools that have already proven their value on making developers more productive. We dedicate our Developer Tools team efforts to the discovery, building, maintenance, and promotion of reusable solutions so that the rest of the engineers don’t have to struggle with repetitive tasks, walk through slow development cycles, or constantly switch contexts to take care of maintenance tasks that can be automated. We want Auth0 engineers to be focused on building new features that solve the hard problems of identity for our customers.

Jorge Fatta

Auth0 Internal Dev Tools: Unleashing Engineering Potential

Try for free today