DevOps for integrations: from first deployment to daily operations

Building the first integration is a project. Running twenty of them is an operation. The order sync between the e-shop and the ERP, the nightly invoice export, the stock feed to the marketplace and the CRM customer sync all need to be changed safely, deployed without surprises, and watched so that a failure on Saturday is noticed before the customer calls on Monday.

DevOps for integrations applies the habits of software delivery (version control, automated pipelines, monitoring) to integration work. This guide covers the building blocks, the common mistakes, and how to compare tools.

Why integrations need their own DevOps thinking

Integrations are software, but they have a few traits that make operations harder than for a typical application:

• They depend on systems you don’t control. A partner’s API changes, a SaaS provider rotates a certificate, the ERP is down for maintenance.
• Failures are often silent. A web page that breaks gets noticed. An order sync that processes zero orders looks, from the outside, exactly like a quiet day.
• They often run on low-code platforms, where “code” is a set of components in a cloud designer rather than files in a repository. Standard Git-based workflows need adapting.
• They move business data. A bad deployment can create duplicate invoices, not just an error page.

The building blocks

1. Environments

At minimum: development (where you build), test (where you test against test copies of the ERP, CRM and e-shop) and production. Larger teams add a UAT or staging environment where business users sign off. The rule that matters: what runs in production is exactly what was tested, with only configuration changed.

2. Version control and packaging

Every release must be identifiable and repeatable: “production runs version 14 of the order sync, deployed on 3 October by Maria, with these notes”. On code-first platforms this means Git and build artefacts. On low-code platforms it usually means the platform’s own versioned packages, optionally exported to Git for history and review.

3. Configuration per environment

URLs, credentials, folder paths and company codes differ per environment. They must live outside the integration logic, set per environment, so the same package can be promoted without editing. (See Managing secrets and certificates across environments in Boomi for one way to do this.)

4. CI/CD pipelines

A pipeline automates the path from “change approved” to “change deployed”: run tests, create the package, deploy to test, wait for approval, deploy to production, record what happened. Even a partial pipeline (automated deploy to test, manual approval to production) removes most of the “who deployed what” confusion.

5. Deployment approvals and change control

Production deployments should be deliberate: a named approver, release notes that say what changed and why, and a known rollback path. For regulated processes (invoicing, payments) this is also an audit requirement.

6. Runtime operations

Integration runtimes need care like any server: capacity, upgrades, disk space for temp files and archives, restarts, high availability for critical flows. With cloud runtimes the vendor takes some of this over, but not all of it.

7. Monitoring, alerting and logging

You need to know: did it run, did it succeed, how long did it take, how much did it process, and is anything stuck. Alerts go to people who can act on them, and logs let you trace a single business document through the flow. We go deeper in Monitoring Boomi integrations.

8. Incident handling

When something fails: who is notified, who decides whether to reprocess, how do you avoid sending the same order twice, and how do you tell the business. A short, practised procedure beats a long, unread one.

9. Documentation and runbooks

For each integration: what it does, which systems it touches, schedule, owner, known errors and how to fix them, how to reprocess, who to call at the partner. A one-page runbook per integration is enough to start.

Do you need all of this?

You need the basics (separate test and production, versioned releases, configuration outside the logic, alerts on failure) as soon as one integration is business-critical. That is usually from day one.

You can postpone full CI/CD automation if you have a handful of integrations, one or two people deploying them and a low change rate. A documented manual procedure with release notes and a rollback step is fine. Automate when releases become frequent, when more people deploy, or when audits ask for evidence.

Common mistakes

• Editing directly in production. Quick fixes that never reach version control, and get overwritten by the next release.
• Configuration inside the logic. Every promotion requires edits, so what reaches production is never quite what was tested.
• Alerting only on errors. The integration that silently stopped running never raises an error.
• Alerts to a shared mailbox nobody reads. Alerts need an owner and a route to someone on duty.
• No rollback plan. “We’ll fix forward” is a plan only if you can do it in minutes.
• Testing only the happy path. See our integration testing guide for what else to test before a release.

How to compare tools

Most integration DevOps setups combine three kinds of tools: the integration platform’s lifecycle features, a general CI/CD tool, and an observability tool. Ask:

1. How does the platform version and package releases? Can you see exactly what is deployed where, and redeploy a previous version?
2. Is there an API or CLI for deployment? Without one, CI/CD is limited to manual steps.
3. How is per-environment configuration handled, and who can change production values?
4. What does the platform expose for monitoring? Execution history, runtime health, events, and whether these can be sent to your central monitoring.
5. Does your organisation already have a CI/CD and observability standard? Fitting into it usually matters more than any single feature.
6. Who will maintain the pipeline? A sophisticated pipeline that only one person understands is a risk of its own.

Tools in this space

These are the tools we come across most often, in alphabetical order.

• Azure DevOps. Microsoft’s suite with Repos, Pipelines and Boards. Popular in organisations on Microsoft 365 and Azure, with approvals and environments built into pipelines.
• Azure Monitor. Azure’s monitoring service, including Application Insights and Log Analytics. A natural place to collect logs and metrics if your runtimes and other workloads are on Azure.
• Boomi. The Boomi platform has lifecycle features built in: packaged components with versions and notes, deployment to environments, environment extensions for configuration, execution history in Process Reporting and runtime health in Runtime Management. The Boomi Platform API (also known as the AtomSphere API) lets external CI/CD tools create packages and deploy them. It fits best when you want release management and operations in the same tool where integrations are built, and connect it to your pipeline tool where needed.
• Datadog. A SaaS observability platform that combines metrics, logs, traces and alerting, with many ready-made integrations. Popular with teams that want one view across cloud services and applications.
• GitHub Actions. CI/CD built into GitHub, configured with YAML workflows in the repository. Easy to start with if your code and scripts already live on GitHub, with environment protection rules for approvals.
• Grafana. Open-source dashboards and alerting, often combined with Prometheus and Loki, and available as a managed cloud service. Favoured by teams that want flexibility and to avoid lock-in to one monitoring vendor.
• Jenkins. The long-standing open-source automation server, self-hosted and extensible through plugins. Still common in on-premises environments, at the cost of more maintenance.
• MuleSoft Anypoint. Combines Maven-based builds and deployment of Mule applications (usually from a CI tool) with Runtime Manager and Anypoint Monitoring for operations. A good fit for teams that prefer a code-first, developer-led workflow.

The best combination is usually the one that matches what the rest of your IT already uses: the integration platform for building and packaging, your company’s CI/CD tool for orchestration and approvals, and your company’s observability tool for alerts.

Where to go next

Two practical articles apply this guide in Boomi:

• Packaging and deploying Boomi processes across environments: packaged components, versions, release notes, rollback and automation from a CI pipeline.
• Monitoring Boomi integrations: Process Reporting, runtime health, alerts and what is worth alerting on.