Product · Engineering
Created 09:40 on Tuesday. Destroyed 16:30 on Friday.
One IBM Maximo environment, from request to destruction. DevForge creates it for one named change, keeps it while that work is live, and tears it down when the change merges. Infrastructure is metered for every hour it exists, and we quote it that way.
One environment, end to end
Four days in the life of an environment that no longer exists.
The change was an extra approval step on high value work orders. Follow it from the request on Tuesday morning to the tear-down on Friday afternoon, 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 useThe defect nobody else has to argue about
The validation fires on the wrong status transition. In a shared environment that becomes a ticket, an argument about who broke it, and a wait. Here it is one developer, one environment, found the next day and fixed the same afternoon.
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.
The point of the whole thing
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
The four days above bought the cheaper of these two
People ask for a test environment and mean one of two things. Read them one at a time.
A clean baseline environment
The version and shape your estate runs, with baseline data. What most development and review needs, and what the four days above used.
- 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
- 4 days
- The whole life of that environment
- 0
- Environments left running after the merge
The clean baseline in the account above. Production-shaped data takes longer and is quoted separately.
Requested Tuesday 09:12, destroyed Friday 16:30, metered for every hour in between.
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
Spend on running environments rises. Spend on waiting for them falls further, and that is usually the larger number.
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.
Bring your environment list and the queue behind it.
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