Reproducible, automated changes and deployments
Infrastructure as code, CI/CD and platforms that make teams faster and operations more secure.
Automation & DevOps at FlixConsulting covers infrastructure as code with Terraform and Ansible, CI/CD with GitLab or Jenkins, repeatable Helm deployments and network automation from a source of truth such as NetBox. It serves IT operations and platform teams in large enterprises, public authorities and critical infrastructure (KRITIS). Changes are versioned, checked and traceable, even in air-gapped environments.
What changes for you
Traceable changes
Changes to infrastructure and network run through pipelines, versioned and approved. They no longer depend on the knowledge of individual people.
Reproducible environments
Test, acceptance and production environments are built from the same code. Differences between environments become visible and can be fixed.
Requirements built into the workflow
Permissions, security checks and approvals are fixed steps in every pipeline. Every run is logged and serves as evidence.
What we take on
Available individually or as a package, from analysis to handover.
- 01
Infrastructure as code with Terraform and Ansible
Servers, virtualisation, network and cloud resources as versioned code: modules, roles and inventories with fixed conventions and code review.
- 02
CI/CD pipelines with GitLab CI/CD or Jenkins
Pipelines for build, test and deployment with protected branches, four-eyes approvals and pinned versions of all dependencies.
- 03
Pipelines for air-gapped environments
Local GitLab runners, Artifactory as an internal repository and Podman as the container runtime, with vetted transfer paths for packages and images.
- 04
Network automation from the source of truth
NetBox or Nautobot supply the intended state, and Ansible uses templates to generate the device configuration from it. It can be validated before rollout, for example with Batfish.
- 05
Workflows and interfaces for NetBox/Nautobot
Plugins, automation jobs and REST interfaces, for example to Artifactory and Ansible, so that network data flows into pipelines without manual transfer.
- 06
Repeatable deployments with Helm
Helm charts and versioned container images that pipelines use to roll out applications on Kubernetes in the data centre or in the cloud.
- 07
Security checks and authorisation concept
Dependency and image scans, linting for Ansible and configurations, checks for credentials in code, and roles for development, approval and operations.
- 08
Separate test and acceptance environments
Environments with the same pipeline definitions as production, without access to classified data where required. Only approved artefacts move on.
What you end up with
- Versioned repositories with Terraform modules, Ansible roles and inventories following fixed conventions
- Documented CI/CD pipelines with approval stages, security checks and a role and permission matrix
- Data flow from NetBox or Nautobot to Ansible, with a validation step and approval for each network change
- Operating documentation and runbooks for pipelines and platforms, with a briefing for your teams
How we work
- 01
Analysis
We capture the toolchain, manual processes, network zones and security requirements, and assess which changes can be automated first.
- 02
Target architecture
We define pipeline building blocks, repository structure, source of truth, permissions and validation steps to fit your requirements.
- 03
Delivery
We build pipelines, modules and deployments for a clearly defined area first and extend them step by step to further systems.
- 04
Handover to operations
We document pipelines, roles and approval processes, brief your teams and hand over code and responsibility to your operations.
- Ansible
- Terraform
- GitLab CI/CD
- Jenkins
- Artifactory
- Batfish
- Podman
- Kubernetes
- Helm
- NetBox
- Nautobot
- Python
In practice
Questions about this service
Where is the sensible place to start with automation?
With frequent, clearly defined changes that are carried out by hand today, such as VLAN changes, server provisioning or deploying an application. There, the process is known and the result can be verified. Network automation requires a well-maintained data foundation. If that is missing, a source of truth such as NetBox comes first.
Do CI/CD and automation work without internet access?
Yes. All components then sit within the isolated network: local GitLab runners, an internal repository such as Artifactory and a dedicated container runtime such as Podman. Packages and images enter only through vetted transfer paths. Your security requirements determine which paths are permitted.
Do existing tools have to be replaced?
Not necessarily. We build on existing tools such as GitLab, Jenkins, Ansible or Chef if they meet your requirements. We only recommend replacing them where security, operations or maintainability justify it. We record the decision and criteria in the target architecture.
Let us talk about your project.
No obligation, confidential and with a concrete next step.