title: "Lesson 15 | Agent-Driven DevOps: CI/CD & Deployment Automation" summary: "Involve Hermes Agent in DevOps processes—automating builds, test runs, Docker image management, and cloud service deployments. A paradigm shift from 'manual operations' to 'Agent orchestration'." sortOrder: 150 status: "published"
Involve Hermes Agent in DevOps processes—automating builds, test runs, Docker image management, and cloud service deployments. A paradigm shift from 'manual operations' to 'Agent orchestration'.
🎯 Learning Objectives
- Understand the Agent-driven DevOps paradigm and its distinction from traditional automation scripts.
- Master how to leverage Hermes Agent's Skills, MCP, and Cron features to automate builds, tests, and Docker image management in CI (Continuous Integration) processes.
- Learn how to orchestrate CD (Continuous Deployment) tasks with Hermes Agent to achieve automated application deployment to remote servers or cloud services.
- Be able to design and implement an end-to-end Agent-driven CI/CD process to enhance development efficiency and deployment reliability.
📖 Core Concepts Explanation
15.1 Agent-Driven DevOps Paradigm: From Scripts to Intelligent Orchestration
Traditional DevOps processes heavily rely on predefined scripts (Shell scripts, Python scripts), configuration management tools (Ansible, Chef, Puppet), and CI/CD platforms (Jenkins, GitLab CI, GitHub Actions). While these tools significantly boost automation, they are inherently imperative: you must precisely tell them what to do at each step. When environments change, exceptions occur, or complex decisions are needed, manual intervention or script modification is the norm.
Agent-driven DevOps introduces a declarative and intelligent orchestration paradigm. An Agent (like Hermes Agent) is not just an executor, but also a decision-maker and a learner. It can:
- Understand Goals: You tell the Agent the desired end state (e.g., "Deploy the latest web application to production"), rather than specific steps.
- Dynamic Planning: The Agent dynamically plans execution paths based on its built-in knowledge, current environmental state, and available tools (integrated via MCP).
- Self-Healing and Adaptation: When encountering unexpected issues, the Agent can attempt to analyze error logs, use its Skills library to find solutions, or even learn new Skills to resolve problems, without requiring manual script modification.
- Cross-Session Memory and Learning: Hermes Agent's Memory (Lesson 04) and Skills (Lesson 03) systems enable it to remember past operational experiences, failure patterns, and successful strategies, applying these experiences in future tasks to continuously optimize its automation capabilities.
Hermes Agent provides a solid foundation for this paradigm through its core capabilities:
- Skills System: Allows the Agent to learn and execute complex, multi-step tasks, which can be abstracted into reusable 'skills'. In DevOps scenarios, these skills could be 'build Docker image', 'run tests', 'SSH remote command execution', etc.
- MCP (Multi-Tool Communication Protocol) (Lesson 06): Provides the ability to interact with external tools (such as Git, Docker CLI, cloud service APIs, SSH clients, etc.). This is the Agent's bridge to the real world.
- Cron Scheduling (Lesson 07): Enables the Agent to trigger CI/CD tasks according to a preset schedule, such as daily builds, regular deployment health checks, etc.
- Context Files (Lesson 08): Allows the Agent to access and understand project configuration files, Dockerfiles, deployment manifests, etc., thereby better perceiving the workspace.
The following table compares traditional script-driven and Agent-driven DevOps paradigms:
| Feature | Traditional Script-Driven DevOps | Agent-Driven DevOps (Hermes Agent) |
|---|---|---|
| Driving Mode | Imperative: Precisely defines each step | Declarative: Defines target state, Agent intelligently plans |
| Flexibility | Lower, requires script modification for environment changes | Higher, Agent can dynamically adapt and self-heal |
| Error Handling | Relies on predefined error capture logic, often requires manual intervention | Intelligent analysis, attempts self-resolution, learns from experience |
| Learning Capability | None | Yes, continuous learning and optimization through Skills and Memory |
| Complex Decision-Making | Relies on manual intervention or complex conditional branching | Agent can make complex decisions based on context and experience |
| Integration Method | Plugins, API calls, script encapsulation | Unified integration of various tools via MCP, Skills abstract operations |
| Representative Tools | Jenkins, GitLab CI, GitHub Actions | Hermes Agent, Autogen, BabyAGI, and other intelligent Agents |
Agent-driven DevOps is not meant to completely replace existing CI/CD tools, but rather to act as an intelligent orchestration layer, raising the ceiling of existing automation and making the entire process more robust, intelligent, and autonomous.
15.2 Hermes Agent in CI Process: Build, Test, and Image Management
Continuous Integration (CI) is a core part of DevOps, aiming to frequently integrate code into the main branch and identify issues through automated builds and tests. Hermes Agent can play a key role in the CI process, automating the following tasks:
- Code Pull and Dependency Installation: Monitor code repositories (e.g., by receiving GitHub webhook events via MCP, or by scheduled
git pullvia Cron). When new commits are made, the Agent can executegit pulland then run the project's dependency installation commands (e.g.,npm install,pip install,go mod download). - Automated Testing: After dependency installation, the Agent can trigger various test suites (unit tests, integration tests, end-to-end tests). If tests fail, the Agent can capture error logs and notify developers via the message gateway (Lesson 05), or even attempt to analyze the cause of failure.
- Docker Image Building and Management: For containerized applications, the Agent can build Docker images based on the
Dockerfilein the project. Upon successful build, it can tag the image appropriately (e.g.,latestor based on commit hash/version number) and push it to a container registry (such as Docker Hub, GitLab Container Registry, AWS ECR).
To implement these functionalities, we need to configure the corresponding Skills for Hermes Agent and potentially integrate external tools.
Example Skill Structure (Pseudocode):
{
"name": "build_and_test_docker_image",
"description": "Pulls code from a Git repository, installs dependencies, runs tests, and builds/pushes a Docker image.",
"steps": [
{
"tool": "shell_command",
"command": "git pull origin main"
},
{
"tool": "shell_command",
"command": "npm install"
},
{
"tool": "shell_command",
"command": "npm test"
},
{
"tool": "shell_command",
"command": "docker build -t my-app:latest ."
},
{
"tool": "shell_command",
"command": "docker tag my-app:latest myregistry/my-app:$(git rev-parse --short HEAD)"
},
{
"tool": "shell_command",
"command": "docker push myregistry/my-app:$(git rev-parse --short HEAD)"
},
{
"tool": "shell_command",
"command": "docker push myregistry/my-app:latest"
}
],
"requirements": ["git", "npm", "docker", "shell_command_tool"],
"inputs": {
"repo_url": "string",
"registry_url": "string"
}
}
In practice, tools like shell_command need to be integrated via MCP. Hermes Agent can execute these Shell commands either through its built-in shell tool (if enabled and configured with security permissions) or by customizing a more secure execute_command MCP tool.
Mermaid Flowchart: Agent-Driven CI Process
graph TD
A[Code committed to Git repository] --> B{Hermes Agent receives notification/Cron trigger};
B -- Cron schedule --> C[Agent: pull_code Skill];
B -- Webhook (MCP) --> C;
C --> D[Agent: install_dependencies Skill];
D --> E[Agent: run_tests Skill];
E -- Test failed --> F[Agent: Notify developer (Telegram/Discord)];
E -- Test successful --> G[Agent: build_docker_image Skill];
G --> H[Agent: push_docker_image Skill to registry];
H --> I[CI process complete];
F --> I;In this way, Hermes Agent can not only execute commands but also make decisions based on execution results (e.g., whether tests passed) and trigger subsequent actions, greatly enhancing the automation and intelligence of the CI process. The Agent can leverage its understanding of context (by accessing Dockerfiles, test reports, etc., via Context Files) and its learning capabilities to optimize build and test strategies. For example, it can remember which tests frequently fail and prioritize running them, or automatically attempt to roll back to the previous stable version when a specific type of error is detected.
15.3 Automated Deployment and Cloud Service Integration: Let the Agent Be Your Deployment Engineer
Continuous Deployment (CD) is an extension of CI, aiming to automatically deploy CI-verified code to production environments. This is a high-risk, high-value stage; the higher the automation, the lower the error rate and the faster the deployment. Hermes Agent can leverage its intelligent orchestration capabilities in the CD process to automate everything from simple SSH deployments to complex cloud service integrations.
Deployment tasks typically involve the following steps:
- Environment Preparation: Ensure that target server or cloud service resources are ready (e.g., virtual machines started, Kubernetes cluster available).
- Credential Management: Securely access sensitive information required for deployment, such as SSH keys, cloud service API keys, etc. Hermes Agent can handle this through its Memory system (encrypted storage) or by integrating with external secret management services (like HashiCorp Vault).
- Application Distribution: Transfer the built application package (e.g., Docker images, JAR files, static files) to the target environment.
- Service Update and Restart: Stop old version services, start new version services, and perform health checks.
- Rollback Mechanism: In case of deployment failure or issues with the new version, be able to automatically or manually roll back to the previous stable version.
Hermes Agent can integrate cloud services and achieve deployment automation in the following ways:
- SSH Remote Execution: This is one of the most common deployment methods. The Agent can connect to a remote server via SSH and execute Shell commands to pull images, update configurations, restart services, etc. This requires the Agent to have a Skill capable of executing SSH commands and securely managing SSH keys.
- Cloud Service CLI/SDK Integration: Integrate cloud service provider command-line tools (e.g.,
aws cli,gcloud cli,az cli) or Python SDKs via MCP. The Agent can directly call these tools to manage cloud resources, such as starting/stopping EC2 instances, updating ECS services, deploying to Kubernetes clusters, etc. - API Calls: For scenarios without CLI tools or requiring finer control, the Agent can directly call cloud service RESTful APIs via HTTP requests. This can be achieved through a generic
http_requestMCP tool or a Skill specifically designed for a particular API. - GitOps Mode: The Agent can monitor deployment configuration files (e.g., Kubernetes YAMLs) in a Git repository. When these files change, the Agent automatically applies these changes to the cluster, achieving declarative deployment.
Example Skill Structure (Deploying to a Remote Docker Host):
{
"name": "deploy_docker_app",
"description": "Connects to a remote server via SSH, pulls, and deploys the latest Docker image.",
"steps": [
{
"tool": "ssh_command",
"command": "docker login -u {{username}} -p {{password}} {{registry_url}}",
"host": "{{remote_host}}",
"port": 22,
"user": "{{remote_user}}",
"key_path": "/path/to/ssh/key"
},
{
"tool": "ssh_command",
"command": "docker pull {{registry_url}}/{{image_name}}:latest",
"host": "{{remote_host}}",
"port": 22,
"user": "{{remote_user}}",
"key_path": "/path/to/ssh/key"
},
{
"tool": "ssh_command",
"command": "docker stop {{container_name}} || true && docker rm {{container_name}} || true",
"host": "{{remote_host}}",
"port": 22,
"user": "{{remote_user}}",
"key_path": "/path/to/ssh/key"
},
{
"tool": "ssh_command",
"command": "docker run -d --name {{container_name}} -p 80:80 {{registry_url}}/{{image_name}}:latest",
"host": "{{remote_host}}",
"port": 22,
"user": "{{remote_user}}",
"key_path": "/path/to/ssh/key"
},
{
"tool": "http_request",
"method": "GET",
"url": "http://{{remote_host}}/health",
"expected_status": 200,
"retries": 5,
"delay": 10
}
],
"requirements": ["ssh_client", "docker_cli", "http_request_tool"],
"inputs": {
"remote_host": "string",
"remote_user": "string",
"registry_url": "string",
"image_name": "string",
"container_name": "string",
"username": "string",
"password": "string"
}
}
Here, ssh_command and http_request need to be integrated into Hermes Agent as MCP tools. Sensitive information like username and password should be securely retrieved from the Agent's Memory or environment variables, rather than being hardcoded directly in the Skill definition.
When executing a deployment Skill, the Agent can make judgments based on the return result of each step. For example, if a health check fails, the Agent can attempt to roll back to the previous version or notify an administrator for intervention. This intelligent decision-making capability is difficult to achieve with traditional scripts. By collaborating with the Agent, we can build more robust and adaptive deployment pipelines.
💻 Hands-on Demo
In this hands-on demo, we will demonstrate how to use Hermes Agent to automate a simple CI/CD process: pulling code from a Git repository, building a Docker image, and deploying it to a simulated remote server. We will use a simple Node.js application as an example.
Prerequisites:
- Hermes Agent installed (Lesson 01).
- Docker installed.
- A simple Node.js project, including
package.jsonandDockerfile. - A simulated remote server (can be another Docker container or VM on your local machine, ensuring SSH access is possible). For simplicity, we assume the local Docker daemon is directly accessible, but deploying to a remote server would require SSH capabilities; here we simulate remote deployment commands.
Node.js Example Project Structure (my-web-app/):
my-web-app/app.js
const express = require('express');
const app = express();
const port = 80;
app.get('/', (req, res) => {
res.send('Hello from Hermes Agent CI/CD! Version 1.0');
});
app.listen(port, () => {
console.log(`App listening at http://localhost:${port}`);
});
my-web-app/package.json
{
"name": "my-web-app",
"version": "1.0.0",
"description": "A simple web app for Hermes CI/CD demo",
"main": "app.js",
"scripts": {
"start": "node app.js",
"test": "echo 'No tests defined yet, but running anyway.'"
},
"dependencies": {
"express": "^4.17.1"
}
}
my-web-app/Dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 80
CMD ["npm", "start"]
Please ensure you have created the my-web-app folder locally and placed the above files inside it.
Scenario 1: Agent Automatically Executes CI Tasks and Builds Docker Image
We will create a Hermes Skill to pull code (here we simulate local directory initialization), install dependencies, run tests, and build a Docker image.
Step 1: Prepare Workspace and Simulated Git Repository
In your terminal, ensure you are in the parent directory of the my-web-app directory.
# Assuming you have already created the my-web-app directory
cd my-web-app
git init
git add .
git commit -m "Initial commit"
cd .. # Return to parent directory
Step 2: Create a Hermes Skill File (ci_skill.json)
We will define a Skill named ci_build_docker. For simplicity, we assume the project directory is in the current directory where Hermes Agent is running. Hermes Agent provides a default shell tool, which we can use directly.
// ~/.hermes/skills/ci_build_docker.json
{
"name": "ci_build_docker",
"description": "Automates code pulling, dependency installation, test execution, and Docker image building.",
"steps": [
{
"tool": "shell",
"command": "echo '--- Starting CI Process ---'"
},
{
"tool": "shell",
"command": "cd my-web-app && git pull origin main || true && echo 'Code pulled or already up-to-date.'",
"description": "Pull latest code (if project is a Git repository)"
},
{
"tool": "shell",
"command": "cd my-web-app && npm install",
"description": "Install Node.js dependencies"
},
{
"tool": "shell",
"command": "cd my-web-app && npm test",
"description": "Run tests"
},
{
"tool": "shell",
"command": "cd my-web-app && docker build -t my-web-app:latest .",
"description": "Build Docker image"
},
{
"tool": "shell",
"command": "docker tag my-web-app:latest myregistry/my-web-app:$(git -C my-web-app rev-parse --short HEAD)",
"description": "Tag image with commit hash"
},
{
"tool": "shell",
"command": "docker push myregistry/my-web-app:$(git -C my-web-app rev-parse --short HEAD) || echo 'Push to registry failed or registry not configured. Skipping for demo.'",
"description": "Push image to registry (simulated here, actual setup requires Docker Hub, etc.)"
},
{
"tool": "shell",
"command": "docker push myregistry/my-web-app:latest || echo 'Push to registry failed or registry not configured. Skipping for demo.'",
"description": "Push latest tagged image"
},
{
"tool": "shell",
"command": "echo '--- CI Process Finished ---'"
}
],
"requirements": ["git", "npm", "docker", "shell"],
"inputs": {}
}
Save the above content as ~/.hermes/skills/ci_build_docker.json.
Step 3: Have Hermes Agent Execute the CI Skill
hermes run "Execute the ci_build_docker skill to build the Docker image for my web application."
Expected Output (partial, actual output will be more detailed, including npm install and docker build logs):
Running with model: openrouter/nousresearch/hermes-2-theta-llama-3.1-8b
User: Execute the ci_build_docker skill to build the Docker image for my web application.
Thought:
The user wants to execute a CI process to build a Docker image. I should use the skill named `ci_build_docker` to complete this task. This skill will handle code pulling, dependency installation, test execution, and Docker image building.
Action:
{
"tool": "execute_skill",
"skill_name": "ci_build_docker",
"inputs": {}
}
Tool Output:
--- Starting CI Process ---
Code pulled or already up-to-date.
added 1 package, and audited 2 packages in 494ms
found 0 vulnerabilities
No tests defined yet, but running anyway.
[+] Building 0.1s (11/11) FINISHED
... (docker build output) ...
Successfully built 0a1b2c3d4e5f
Successfully tagged my-web-app:latest
The push refers to repository [docker.io/myregistry/my-web-app]
... (docker push output - may show error if registry not configured) ...
The push refers to repository [docker.io/myregistry/my-web-app]
... (docker push output - may show error if registry not configured) ...
--- CI Process Finished ---
Thought:
I have successfully executed the `ci_build_docker` skill, completing the CI process, including code pulling, dependency installation, test execution, and Docker image building. Although pushing the image to the registry might have failed due to local configuration, the core build and test steps are complete.
Action:
{
"tool": "send_message",
"message": "The CI process has been successfully executed, and Docker images `my-web-app:latest` and `myregistry/my-