:chart_with_upwards_trend: Today, we have more tha...
# general
📈 Today, we have more than 1000 repositories developed by 300+ engineers across 5 locations. Our CI/CD system efficiently handles approximately 15,000 monthly deployments. Additionally, our developer productivity team (13 DevOps engineers), has implemented an in-house solution that provides each engineer with a cloud development environment, supplying over 300 on-demand sandboxes 🤘 In response to these numbers, we provide various tools to enhance the developer efficiency of our product development teams 🧑‍💻 🧵 In the thread, you’ll find brief descriptions of 12 developer productivity tools (one is also mentioned in The Pragmatic Engineer blog among Uber and Slack solutions), and I’d love to know which ones caught your attention. Your feedback will guide me in prioritizing a more comprehensive article, where I (or one of my colleagues) will provide more insights into the problem statement, potential solutions, and the results we’ve achieved 👌 📣 Additionally, I’m eager to learn about any developer productivity tools invented within your company. Even a single sentence about an internal tool could inspire others in the industry. Let’s exchange ideas and see where our collaboration leads us! 👀
SPoT (stands for Single Place Of Truth) is an internal service manager that gathers data from all our repositories stored in GitHub. It offers insights on ownership, programming languages, package versions, dependencies and their tree, lines of code, vulnerabilities, and more, ensuring consistent knowledge about our repositories The repository.json file, located in the root directory of every repository, contains metadata that can’t be directly or indirectly extracted from the codebase. This includes details such as the repo type (whether it’s a service, library, or application), the owner, a short description, and configurations used by deployment automation tools. This metadata provides a comprehensive overview of our services and libraries in SPoT. Rakett is an orchestrator with a UI specifically designed to manage and speed up automated deployments. Built on top of Jenkins, it provides detailed progress visualization throughout the various CI/CD pipeline stages. Rakett’s key features include visualizing deployment targets and their history, pausing or releasing components as needed, and seamlessly rolling back changes for broken components. Neodora (stands for New Deployments Or Repository Analyzer) is a tool that examines repositories and deployments to uncover potential issues. Using static code analysis and checking data against specific rules, Neodora validates various configuration files, including YAML and JSON. Its purpose is to detect bugs, misconfigurations, and security vulnerabilities. Automatically triggered with every GitHub commit, Neodora ensures that changes align with our company’s defined standards, thereby enhancing the overall quality and security of the code Devbox is a cloud-based development environment sandbox hosted in AWS (mentioned in The Pragmatic Engineer blog among Uber and Slack solutions). Engineers interact with it through a CLI tool, writing code on their own computers but executing it within Devbox. This remote and reproducible environment fosters faster and more efficient development cycles, ensuring that each coding session is isolated and controlled. Testbox is a fully automated, on-demand sandbox environment that enables developers to create ready-to-code test environments in AWS. Engineers and other team members can use testbox to share development results and run tests in a fully tailored environment. Ready in just 2 minutes, the testbox stays up-to-date with the latest changes, mirroring production configurations. Testdata-API is a service designed to manage all test data in testboxes (including devboxes) and other test environment regions. It handles various functions, such as creating, removing, and managing users and their settings, as well as managing feature flags and other related tasks. Devbox-Proxy provides an immutable HTTP endpoint, allowing developers to call services in their currently active Devbox. This convenience enables access to services inside the devbox via a single endpoint (such as https://devbox-proxy.domain.com), without specifying the container address. The Devbox Proxy facilitates two types of proxying: forward, which simply passes the request onward, and redirect, used specifically for callback URLs. Deploy Dependabot GitHub Action is created to automatically approve and deploy Dependabot PRs for services and libraries. Through its configuration, users have the flexibility to exclude packages they don’t want to auto-merge, restrict PR deployments to working hours or specific timeframes, designate which dependencies should be deployed (either development or all), and decide whether or not to update dependencies of dependencies. Helm-template is our internal opinionated chart template dependency used by every service. It helps us generate Kubernetes files in a predictive way by injecting any resource definitions we need. Helm-template auto-update GitHub Action is designed to automatically update minor or patch versions of the Helm-template within pull requests if the version used in the service is behind the latest one for minor or patch versions. These versions are upgraded by creating a separate commit with a version bump to a newly created PR, ensuring an up-to-date version of the Helm-template is consistently utilized across all repositories. Doorman is a developers’ tool that provides a convenient and secure way to make HTTP requests to live services. Removing the need for developers to have direct access to live services enhances the system’s overall security. All requests are authenticated, and a history is maintained. Doorman receives these requests from the UI and then forwards them to the appropriate target services in the correct environment and region.
I thought this was super interesting and would like to read more. I found your medium page and checked out a few articles, thank you for sharing!