1. Introduction
2. Automation as Culture
3. Introducing Deployer
3.1 Why Did We Build Deployer?
3.2 What Does Deployer Do?
3.3 Architecture and Technical Design
4. Available Slack Actions
5. Deployer Control Panel
6. Security
7. Future Vision
Introduction
Over the course of our journey, the automation of critical processes has become a strategic and essential component of our development team’s workflow.
Working with a wide range of services and technologies, combined with the numerous steps required before each release, makes it essential to rely on tools that ensure secure and robust deployments. In a context where speed and security are key, automating repetitive tasks not only minimizes the risk of human error but also allows us to focus on the core of our work: building valuable solutions.
Automation as Culture
Implementing automation policies in a development team represents a substantial improvement in process management. However, such a transformation doesn’t happen overnight. It requires constant analysis and iteration, where we apply our accumulated experience to continually refine our workflows.
It is also crucial to highlight that building an efficient and adaptable continuous integration ecosystem demands the collaboration of various technical profiles, ensuring long-term scalability and evolution.
Furthermore, adopting this kind of system implies a significant methodological shift, ultimately impacting team culture and practices — from DevOps engineers to developers, QA specialists, and project managers — all of whom play a key role in this transformation.
Introducing Deployer
One of the key components acting as a bridge between the team and the CI/CD systems we use at O2O is our newly developed tool: Deployer. Created in 2024 and launched in early 2025, Deployer has become the central pillar of our deployment automation strategy.
¿Why Did We Build Deployer?
Deployer was born from the need to adapt to a new era in which relying on a single CI/CD system is no longer viable. The wide variety of project types we handle means that each one requires different architecture, infrastructure, and technological conditions for building and deployment.
Additionally, working within a multidisciplinary team on highly diverse development scenarios forced us to design a solution that could adapt to the largest number of possible use cases. That meant creating a flexible component, agnostic to whether the deployment involved a mobile app, a web platform, or a service hosted in any of the leading cloud environments.
¿What Does Deployer Do?
Via a simple chatbot, Deployer allows users to submit various types of deployment requests directly. These requests are executed through the corresponding CI/CD system configured for the specific project.
Furthermore, we ensure that all deployments to protected environments go through a validation system built into the platform. This guarantees that any production release has received approval from all necessary stakeholders before going live.
Architecture and Technical Design
The chatbot is a Slack application that connects to a backend developed in PHP, communicating with various CI/CD providers via custom integrations. In the case of Jenkins, we use its REST API with basic authentication via access token.
We also developed a custom plugin that allows the CI/CD system to notify Deployer about the status of each triggered job. This enables real-time updates, linking job outcomes to the original request.
Since our goal is to continue evolving Deployer, it was built as a modular system. The logic is abstracted based on pipeline type and CI provider, which will allow us to support new systems in the future without needing to refactor the core.
Available Slack Actions
From the beginning, we aimed to offer a minimal yet functional set of direct actions accessible via Slack — enabling the team to act quickly and securely. At the same time, we designed the system to evolve incrementally as new use cases emerge.
The current set of available actions includes:
- User Linking. Automatically links a Slack ID to the corresponding Deployer user. This is essential for validating permissions and maintaining deployment traceability.
- The core action of the system. Allows users to submit deployment requests by selecting the platform, project, branch, and target environment.
- My Deployments. Displays a personal history of the user’s most recent deployment requests, including project name, environment, branch, creation date, and deployment date.
- Repeat Deployment. Lets users re-trigger a previous deployment from their own history using the same parameters — especially useful for rapid iteration in test environments.
- Approve Deployment. Manages the approval system for protected environments. Collects validations from key team roles to ensure defined requirements are met before authorizing the deployment.
While this base set covers current needs, we are already exploring new features such as deployment cancellation, scheduled deployments, or automated failure notifications.
Deployer Control Panel
Another major improvement we aimed for with Deployer was the addition of a visual control panel for easily managing deployment configurations, user roles, and permissions. For this, we built the interface using the Tabler Admin Template, a robust open-source dashboard solution.
Source: Tabler – https://tabler.io/admin-template
Thanks to Tabler, we were able to create a clean, functional UI without investing excessive frontend resources. Its ready-to-use components allowed us to focus on delivering features that add real value to our team.
Additionally, the Deployer control panel centralizes all deployment logs in a single place. This enables full traceability of automated releases and supports the generation of audit-friendly reports and deployment evidence.
Security
Deployer gives us full control over deployments through its protected environment configuration. Any deployment targeting a protected environment must be explicitly approved by predefined project roles. Every action is logged with the author’s name, date, target environment, approvals, and status.
Access to the control panel is managed via LDAP authentication integrated with our corporate directory. Once a user is registered, role-based permissions are configured based on their Slack ID, allowing Deployer to verify the user’s identity before executing any operation.
Future Vision
With Deployer, our goal was not only to solve a specific need, but to build a maintainable and scalable platform that could grow alongside us.
While Deployer was conceived as an internal tool, its design allows for seamless adaptation to other environments. Thanks to its flexibility, we plan to add new features aligned with our evolving roadmap. Some examples include:
- Integration with new CI/CD providers. Expanding compatibility with additional systems used by our clients.
- Development of an MCP Server for LLM communication. Building a middleware layer that connects Deployer with AI services to enable natural language interactions and intelligent suggestions.
- Support for other communication platforms such as Microsoft Teams. Adapting chatbot functionality beyond Slack.
- Multi-language support. Translating the control panel based on each user’s language preferences.
- Metrics dashboard. Visualizing tool usage, deployment performance, and error analytics directly in the control panel.
- Version management for native or hybrid app artifacts. Creating a downloadable artifact repository within Deployer, with version history for easier testing and sharing with QA teams or clients.