Working with Project Copies

Migration programs often need to pin down part of the work for go-live while other parts keep moving. Hopp Studio supports this with a project copy: a separate version of the project, created from a chosen commit, that can change independently of the original.

This mechanism can be used for two different purposes:

• Stabilize: is to hold a version of the project unchanged ahead of an upcoming go-live, so further development does not disturb what was approved.
• Parallel Workstreams is to run two or more overlapping streams of work in one program, each with its own go-live date.

Both purposes rely on the project copy and drift mechanics described in The Studio Repository. This article describes when to use each purpose and how to run them in practice. Both involve Hopp Studio, where the Maps live and where copies are managed, and Visual Studio, where the Engine projects are generated and deployed.

Two terms appear throughout this article:

• main: the original project, the one that exists before any copies are made.
• copy: a separate project derived from main at a specific commit. After creation, the copy can change independently of main, and main continues to change independently of the copy.

The two use cases

Stabilize shows up around every go-live when a delivery needs to be protected from further development.

Parallel Workstreams shows up in larger programs that have to manage multiple deliveries at once.

	Stabilize	Parallel Workstreams
Purpose	Hold a tested and approved version unchanged ahead of an upcoming go-live	Run two or more overlapping streams in one program, each with its own go-live
What runs on main	Continued general development	Continued development. Stream B builds on it.
What runs on copy (drift)	Not expected. Only must-do hotfixes uncovered at go-live or in its run-up	Expected. Stream A's ongoing work

The contrast matters when looking at drift. On a Stabilize copy, a drift entry is a signal that something needed an emergency fix. On a Parallel copy, drift entries are the expected output of Stream A's ongoing work.

Stabilize

A version of the project has been tested and approved for an upcoming go-live. The team needs that version to remain unchanged from approval through go-live, while the rest of the team continues general development on main.

Without a freeze, even small changes between approval and go-live can introduce risk: an item that was tested may behave differently because something around it changed.

Scenario

A Stabilize run follows a predictable sequence between approval and go-live, with the copy holding the approved state through the window.

In the diagram, m1, m2, … mark commits on main, and h1 marks a hotfix commit on the copy.

1. The project reaches tested and approved status, ready for the upcoming go-live.
2. A copy of the project is frozen at that commit.
3. Between the freeze and go-live, main continues with general development (new bug fixes, refactoring, work toward future deliveries). The copy stays untouched.
4. If go-live or its run-up uncovers a must-do hotfix, the change is made on the copy. The same fix is also applied to main if needed there.
5. Go-live runs against the frozen copy.
6. Afterwards the copy may be retained as a record of exactly what went live, which is useful for audit and for reproducing the deployed state later.

Creating the copy

A copy can be created from any commit in the project's history. From the Repository View on the root node of the project, open the History tab and select the commit that corresponds to tested and approved. Use Create a new project copy based on the selected commit. The available actions on this view are described in The Studio Repository.

How drift behaves

On a Stabilize copy, drift is not expected. The whole point of the copy is that it does not change.

If go-live or its run-up uncovers a must-do hotfix, the change is made on the copy and recorded as drift on the Copies tab. Must-do means the issue blocks go-live; nice-to-have improvements belong on main, where they can be picked up in a later delivery. After applying a hotfix to the copy, evaluate whether the same fix needs to be applied to main and apply it there if so.

Engine coordination

The Engine project for the upcoming go-live lives in the shared Visual Studio solution and is generated from the copy. The main project may have its own Engine in the same solution that continues to evolve for ongoing development. Engine generation against the copy is typically a one-time activity around go-live: generate, verify, deploy, and that Engine then sits unchanged unless a hotfix triggers a regeneration.

Considerations specific to Stabilize

Choosing the freeze commit. A copy can be created from any commit in the history, which is what makes this work. Choose the commit that matches what was approved, not just the latest. The right commit may sit several commits back if main has continued to develop in the meantime.

Hotfix discipline. Treat any change to the copy as a hotfix decision, not a routine edit. The commit history of the copy should remain short and tied to the go-live. If the team finds itself making routine changes on the copy, that is a sign that something other than a hotfix is going on.

Parallel Workstreams

A program has overlapping deliveries on different dates. The work splits into separate streams, each owning the items going live on its own date. This shows up in larger migration programs where the scope is too big to deliver in a single go-live but the stream owners do not want to wait for each other to finish.

The streams overlap in time. From the moment a stream creates its copy until that stream goes live, more than one stream is active at the same time. This shared window is where the program is running streams side by side. Most of the coordination is Stream B reviewing what has changed on the copy and deciding what to also apply on main.

The drift list goes one way

The Copies tab allows Stream B to see which items have changed on the copy, so each change can be reviewed and, if needed, applied to main.

The reverse direction has no such list: if a change made on main is also needed on the copy, Stream A has to spot it and apply it on the copy. Plan around this when deciding what each stream takes on.

Scenario

In a typical two-stream Parallel Workstreams run, the timeline spans both deliveries. In this scenario Stream A has the earliest to-live date and Stream B follows later.

Stream A is a parallel delivery that branches off onto a copy, develops there, and goes live from it. Stream B is the continuing work on main.

In the diagram, m1, m2, … mark commits on main, and d1, d2, … mark drift commits on the copy.

1. Stream A needs to branch off from Stream B's continuing work on main. A copy is created at that point, giving Stream A an isolated workspace to develop in.
2. Stream A continues its work on the copy. Stream B stays on main and continues toward its later go-live.
3. Drift accumulates on the copy as Stream A's work proceeds. These are real changes that the project may want to keep.
4. Stream B reviews the drift list regularly. For each item, decide whether the same change is needed on main: if yes, bring it back into main; if not, mark it as specific to Stream A. Every drift item is reviewed and accounted for.
5. Stream A goes live from the copy.
6. Stream B continues on main and eventually goes live. By then, main carries the latest go-live and contains everything from Stream A that was relevant plus everything Stream B built.
7. Afterwards the copy may be retained as a record of exactly what Stream A delivered, which is useful for audit and for reproducing the deployed state later.

Engine coordination

Each stream has its own Engine project in the shared Visual Studio solution:

• Stream A's Engine generates from the copy.
• Stream B's Engine generates from main.

Naming should make the target deployment unmistakable. Pair each Engine name with the stream or the go-live it serves, so there is no ambiguity at deployment time. Deployment ordering follows the go-live calendar: Stream A's Engine is deployed first, Stream B's afterwards.

A clean naming convention is more important here than it sounds, because both Engines exist side by side for the duration of the parallel work, and a wrong deployment from the wrong project is hard to undo cleanly.

Considerations specific to Parallel Workstreams

Timing of the split. This is the primary consideration. Too early and Stream A misses improvements that arrive on main between the split and its own go-live; there is no drift list going that way, so anything Stream A also needs would have to be spotted on main and re-applied on the copy by hand. Too late and Stream B's continuing work on main is already diverging in ways the eventual drift review has to untangle.

The fact that a copy can be created from any commit in the history is also useful for recovery. If the team realizes the split should have happened at a different commit, a copy can still be created from that commit. The discussion about timing should happen ahead of the split, not after.

Drift-review discipline. Stream B reviews the drift list regularly, not at the end. A backlog of unhandled drift becomes painful exactly when Stream B is approaching its own go-live. Build the review into the team's routine: a brief weekly walkthrough is enough for most projects.

Scope of changes on the copy

Stream A only does work on the copy that is for its own delivery. Anything for Stream B belongs on main. The drift list only covers one direction, so if Stream B does something on main that later turns out to be needed on the copy, someone has to spot it and re-apply it there. Mixing scopes on the copy just builds up that kind of manual re-work.

More than two streams

The two-stream pattern described above is the most common form, but the mechanism is not limited to two streams. A copy can be created from another copy, so a program with three or more overlapping deliveries can branch further: a copy for the earliest go-live, a copy of that for the next, and so on. Drift then flows back through the chain, with each stream reviewing the drift of the streams that go live before it.

In any tool, including Hopp Studio, the coordination cost rises sharply with each added stream. Each additional stream adds another workspace to coordinate, another drift list to review, another Engine to keep clearly named, and another set of stakeholders to align. Drift is still tracked only one direction along the chain, so every change going the other way has to be spotted and applied by hand. The benefit is isolation between deliveries. The cost is coordination, and that cost grows faster than the number of streams.

A program running three or four parallel streams should ask whether sequencing the deliveries differently, with one go-live at a time and shorter overlap windows, would be lower-risk than the parallel split.

Further reading

For the underlying mechanics, see:

• The Studio Repository for the Copies tab and drift handling.
• Studio Commits for commit history and labels. Adding a label to the commit a copy is created from makes that point easy to find later, which helps if the project history is long.