Product · Engineering
Five objections to a Maximo deployment pipeline, taken in order.
Pipelines collects applications, security groups, automation scripts, integrations and reports as one versioned release, builds once, tests, gates through Change Control, then applies to production. Below are the five reasons estates give for why it cannot work on theirs, hardest last, each conceding the part that holds.
Before the first objection
What the pipeline is, in flat terms
What a release is
- What moves
- One versioned release set, built once and applied everywhere.
- What does not move
- A person, onto the production system, working from a document.
- What gets written
- What was applied, by whom, on whose approval, as it happens.
- Objects carried
- Applications, screens, security groups, automation scripts, integrations, reports.
Where it runs
- Platforms
- Classic Maximo 7.6.x and IBM Maximo Application Suite.
- Production gate
- A named approver, with the decision recorded in Change Control.
- Test environments
- Your own, or short-lived ones from DevForge.
- Your toolchain
- Runs alongside it. The build farm stays the build farm.
Driving production releases on Maximo and MAS estates MaxIron delivers and operates, with Change Control at the gate and DevForge supplying test environments.
The five objections
Each one harder than the one above it
None of these is a platform problem. Each is what happens when no promotion path was built, so capable engineers do skilled, unrepeatable work by hand.
- 01
“Maximo configuration is not code, so there is nothing to promote.”
- What is true in it
- It is not a source tree. Changes live as objects inside the estate, with dependencies between them.
- Generic CI/CD has no model of those objects, so promotion becomes a numbered step list performed again in each environment.
- What answers it
- Collect. The change leaves development as one versioned release set.
- Build once. One artefact moves everywhere, so what test saw is what production gets.
Configuration is a versioned object set, and that can be promoted, tested and rolled back.
- 02
“Our production changes are made by hand, and always have been.”
- What is true in it
- Hand deployment is skilled work, usually held by one engineer who knows the order of operations.
- It forces midnight windows, and step nine failing at 02:00 cannot be repeated exactly the next time.
- What answers it
- The change is performed once in development and applied by the pipeline. Nobody signs in to production to perform steps.
- Reversal removes the release the pipeline put in. Urgent change takes a fast lane with the same tests and the same approval.
A Saturday window and a fourteen-step document become a weekday promotion that waits on approval, not on an engineer being awake.
- 03
“Automation means losing the approval we are audited on.”
- What is true in it
- Hand deployment feels accountable: a named person did it at a known time.
- What is usually weak is the evidence, gathered weeks later from screenshots and approval mail.
- What answers it
- The pipeline builds, applies to test, runs checks, then stops. It does not decide production.
- A person approves a specific release with its test result, Change Control records that decision, and only then does the artefact move.
The audit question changes from whether an engineer followed a document at 01:30 to which release went where, which tests it passed, and who accepted it.
- 04
“The tooling expects a build artefact and an automated test suite. We have neither.”
- What is true in it
- There is no compile step and no binary for a generic pipeline to gate on.
- Thin regression coverage stays thin once it is automated.
- What answers it
- The release set is the artefact: versioned, readable, with its test result attached.
- The gate accepts the assurance you have today, automated or functional sign-off. Deepening coverage is separate work, not a precondition.
The answer is not a Maximo binary. It is a versioned release that gets tested and approved.
- 05
“We tried this once, and the environments drifted apart anyway.”
- What is true in it
- A pipeline does not repair drift it inherits, and the same release on two different estates gives two different results.
- Where environments are scarce or permanently booked, there is nowhere honest to run checks.
- What answers it
- Every environment receives the same artefact from the same pipeline, and live production fixes go back through that path.
- DevForge supplies short-lived environments that have not had two years to drift.
A pipeline across four divergent environments produces confident nonsense, so fixing the environments is part of the work.
Objection two, shown as one release
A screen change, a script and an integration mapping, promoted together
One release: a new work order field and its validation, the automation script behind it, a security group change, and an integration mapping to finance.
By hand, today
Four environments, four performances of the same change
- 1
Written up as steps
Fourteen steps in order, with rollback at the end. The document is the release.
- 2
Performed again in test
Two steps differ from the first performance because the document was ambiguous.
- 3
Applied at one in the morning
Step nine fails, the endpoint is corrected live, and that correction is never recorded.
- 4
Evidence assembled in arrears
Weeks later, screenshots, approval mail and recollection are stitched into an answer.
Through Pipelines
One artefact, applied four times without being retyped
- 1
Collected as a release
Screen, script, security group and mapping collected as one named, versioned release.
- 2
Applied to test, unchanged
The pipeline applies that artefact. There is no second interpretation.
- 3
Approved before production
The approver sees contents and test results on a Tuesday afternoon.
- 4
Applied by the pipeline
The same artefact reaches production with nobody signed in, recorded as it goes.
The change is safer because it was the same change in every environment, tested before the gate and approved before it moved.
Objection three, at the gate
One release through the production gate
Automated up to the gate, a person at it. The release number is illustrative; the order is not.
-
Beat 1
Release 2026.04.2 is built once and applied to a test environment.
Written The release set and its contents, versioned.
-
Beat 2
Checks run against that artefact, and the pipeline stops at the production gate.
Written Pass or fail, attached to the release rather than to a date.
-
Beat 3
A change approver reads what the release contains and what the tests did, then approves the window.
Written Who approved, what they were shown, and when, in Change Control.
-
Beat 4
The pipeline applies the same artefact to production. No engineer signs in to perform steps.
Written What was applied, where, and at what time, as it happens.
-
Beat 5
If it has to come out, the pipeline removes the release it put in.
Written The reversal, against the same release.
Promotion to production is not something the pipeline decides. It builds, tests, then stops and waits for a name.
Objection four, held apart
What a repeatable path guarantees, and what a tested change proves
Buyers ask for automation and often mean assurance. Only one of the two belongs to a pipeline.
The path
The same change into every environment the same way, with the record written while it happens. This is what Pipelines does.
The assurance
Deciding the change is correct and proving it behaves. Pipelines runs your tests; it does not author them.
The question it answers
Did exactly this release reach production, and who approved it?
Is this release the right change, and does it work?
Who owns it
Pipelines, with Change Control holding the production gate.
Your functional leads, your testers and the business owner of the process.
The failure it prevents
A change applied differently in production than it was in test.
A change applied perfectly that was still the wrong change.
The arithmetic after all five
Testing still costs what it costs. Releasing stops costing a weekend.
Writing tests, functional acceptance and data fixes cost the same after automation as before. What comes out of every release is performing the change again per environment, reconciling drift, the undocumented 01:00 correction, and one person being the only safe releaser.
Boundaries
Three limits on what a pipeline carries
An oversold release process is one nobody trusts the second time.
It does not write your tests
Pipelines runs your assurance and attaches the result. Thin coverage stays thin once automated, and building coverage is scoped separately.
It does not make a bad change safe
A wrong change can be collected, tested, approved and applied accurately. The path is repeatable; the judgement is still yours.
It is not your build farm, and it needs somewhere to test
Pipelines assumes a production-like test environment. Where environments are scarce, DevForge is the other half.
MaxIron Pipelines, frequently asked questions
- Why does Maximo need its own CI/CD product?
- Maximo estates change as applications, screens, security groups, automation scripts, integrations and reports. Generic CI/CD cannot move those as one release, because it has no model of the objects or their dependencies.
- Do we have to change our test process first?
- No. Pipelines runs the assurance you have today and attaches the result to the release. Deepening automated coverage is separate work.
- What happens when a release fails in production?
- The release comes back out: the pipeline knows what it applied, and both promotion and reversal are recorded. Some data changes cannot be undone by a release.
- How does this sit with Change Control?
- Pipelines uses Change Control as its production gate, which is what gives regulated estates the approval record alongside the engineering discipline.
Bring the runbook you release from.
Bring the runbook, wiki page or ticket checklist that describes how configuration reaches production today. We show which steps become one release artefact, which stay as your tests, and where approval sits.
Bring this to the first call
- The current production release runbook, however rough
- The environments a change passes through, and which still resemble production
- Your last two production changes, and whatever evidence exists for them
- The objection above that you think we answered least well