MaxIron Portal
Get a Maximo environment for one change.
DevForge creates a clean Maximo environment for the change you are working on. It stays up while you build and review. When the change is merged, the environment is removed. You pay for the hours it exists, and nobody waits for the shared test box.
DevForge is provided through MaxIron Portal. Scope and price depend on the environment shape, lifetime and delivery controls required. Quote on request.
One environment, end to end
One environment, from Tuesday morning to Friday afternoon.
The change was an extra approval step on high-value work orders. Follow it from the request to the tear-down, with what was written down at each point.
Tue 09:12
RequestedThe change is given its own environment the same morning
A supervisor wants an extra approval step on high value work orders: one field, its validation and two roles. The developer requests an environment for that change, and the request carries an owner, a reason and an expiry from the first minute.
What happens
-
Request
One environment for the work order approval change.
-
Developer
Names the change, the estate shape and the expected duration.
-
DevForge
Queued with owner, reason and expiry.
Tue 09:40
CreatedTwenty eight minutes later there is somewhere to work
A clean IBM Maximo environment on the version and shape of the target estate, carrying baseline data only. Production volumes are a separate, governed request, and conflating the two is how customer data ends up somewhere nobody signed off.
What happens
-
DevForge
Clean baseline on the current version. Baseline data only.
-
Developer
Builds the field, the validation and the security group change alone.
-
Cost
Metered from creation until destruction.
Wed 14:20
In useReproduce and correct the defect in its own environment
The validation fires on the wrong status transition. The developer reproduces and corrects it in the environment assigned to this change, then reruns the checks without interrupting other work.
What happens
-
Developer
Reproduces, fixes, retests. Nobody else affected.
-
Environment
Change rebuilt the same day. No queue.
Thu 11:05
ReviewedThe reviewer uses the change instead of reading about it
The reviewer opens the environment, raises a work order above the threshold, and watches the approval step and the two roles behave differently. Both of their comments concern behaviour a screenshot could not have shown.
What happens
-
Review
A running environment attached to the change.
-
Reviewer
Exercises it and approves on behaviour.
-
Record
Approval logged against the review environment.
After the change is merged
Fri 16:30
GoneThe environment stops existing, on purpose
The change merges and reaches production through the release path. The environment is destroyed the same afternoon, rather than archived or renamed for the next job. Four days of infrastructure bought an early defect and a review somebody performed.
What happens
-
Developer
Confirms the merge. The environment is finished.
-
DevForge
Destroyed. Metering stops.
-
Production path
Change reaches production through Pipelines.
Two requests that arrive as one
Choose a clean baseline or production-scale test data
Choose the data needed to build or test the change. A clean baseline and a copy with production-scale data require different preparation and approvals.
A clean baseline environment
A clean environment on the version and shape your estate runs, with baseline data for development and review.
- How long it takes
- Minutes.
- What it is for
- Building a change, reviewing behaviour, reproducing a defect, rehearsing an idea.
- Who has to agree
- The delivery team.
- What it costs
- Small, and it ends when the work ends.
A production-shaped data environment
Real volumes, real relationships, sometimes real personal or commercial data. What some testing genuinely needs, and what your governance exists for.
- How long it takes
- Longer. Copying, masking and checking data is work, and your data sets the duration.
- What it is for
- Performance work, migration rehearsals, integration volume testing, upgrade dry runs.
- Who has to agree
- Whoever owns the data. A short-lived environment relaxes no obligation.
- What it costs
- More, for as long as it exists.
The two numbers that decide this
How fast it arrives, and how long it lives
-
28 min
Request to a working environment
The clean baseline in the account above. Production-shaped data takes longer and is quoted separately.
-
4 days
The whole life of that environment
Requested Tuesday 09:12, destroyed Friday 16:30, metered for every hour in between.
-
0
Environments left running after the merge
Owner, reason and expiry are set at request, and tear-down is enforced rather than remembered.
Where the time and the money go
On-demand environments move the cost from waiting to compute
Compare the compute and storage used by each temporary environment with the delivery time spent waiting for shared test capacity.
Unchanged, and we would not claim otherwise
Still costs exactly what it costs
- Compute and storage for every hour an environment exists
- Production-shaped data refresh, masking, checking and approval
- Writing and running tests
- The controlled path to production
Gone, on every piece of work
No longer part of delivery
- Waiting weeks for the one shared environment
- Work colliding for lack of anywhere else to go
- Review from a description and two screenshots
- Permanent environments idling between the weeks they are contested
One environment existed for four days, carried one change, surfaced one defect early and was destroyed on the Friday. A permanent environment for the same change would still be running.
Infrastructure spend becomes attributable to a piece of work.
Dates, duration and creation time are illustrative, shaped like work MaxIron runs. In active use on MaxIron implementation, MAS upgrade and managed support programmes, where parallel work proceeds without queuing and throwaway upgrade rehearsals are created per estate rather than shared.
Boundaries
Three constraints stated before the first invoice
These decide whether the model works in your organisation.
An environment costs money while it exists
DevForge creates more environments than you run today, and the saving comes from them ending. Ownership, expiry and enforced tear-down are part of the product for that reason.
Production-shaped data carries its own governance
Refreshing with real data is a data protection and commercial confidentiality decision before it is a technical one. We build the masking and the refresh; your data owner approves each cycle.
The release gate stays where it is
On-demand environments remove the queue and leave the gate standing. Changes still pass through Pipelines, and DevForge supplies somewhere safe for a change to be wrong first.
MaxIron DevForge, frequently asked questions
- How quickly can a new environment be ready?
- Minutes for a clean baseline on the version and shape of your estate. Longer where production-shaped data has to be copied, masked and checked, and that duration is set by your data rather than by our tooling.
- What stops us ending up with thirty forgotten environments and a large bill?
- Every environment carries named work, an owner and an expiry, and tear-down is enforced rather than remembered. Infrastructure cost ties back to the change that caused it.
- Does this remove the need for a release process?
- No. DevForge is build and review space. The controlled path to production is Pipelines, with the production gate held by Change Control.
- Does it work for classic Maximo as well as MAS?
- Yes. Classic Maximo 7.6.x and IBM Maximo Application Suite are requested and torn down the same way.
- How does this fit a pull request review?
- Each pull request can carry its own environment, so the reviewer exercises the change rather than reading a description. It is destroyed after the merge.
See DevForge with your environment list
Your non-production environments, what each is doing this week, and the work waiting for one. We show which waits disappear, which requests are really data refreshes, and what the infrastructure line looks like when environments end.
Bring this to the first call
- The non-production environments you run today, and what each one is for
- The work waiting on an environment now, and how long it has waited
- Which testing genuinely needs production-shaped data, and who owns that data
- Your current monthly cost for non-production environments