Final mini project
Final Exercise
Final mini project
This final exercise lets you repeat the full beginner workflow without reading the earlier lessons line by line.
Create and distribute a tiny assignment called shape-workshop with:
- one distribution named
WS1 - at least two generated repositories
- one placeholder-based template
- one
individualization.jsonwith two simple variation axes - one successful real distribution
- one verified result using state files and overview commands
Success criteria
By the end of the exercise, you should have:
- a new origin repository
- a configured distribution
- a working individualization file for
ShapeandColor - generated
individuals.json - generated
remotes.json - a verified remote result on your GitLab target
Before you start
Reuse the host alias you configured earlier in the course.
Before you begin the exercise, make sure you have:
- one GitLab group or namespace where you may create the new repositories
- one concrete
groupIdfor that target - at least one real account you can use to test member assignment
If you only have one safe test account, reuse it on two lines of the member input — each line becomes its own group and generated repository.
Build a minimal assignment around the placeholders $Shape$ and $Color$.
Possible variation values:
CircleSquareTriangle
Possible color values:
RedBlueGreen
Suggested file idea
Your template can be as small as this — put the placeholders into the file name too, for example src/$Color$$Shape$.java:
public class $Color$$Shape$ {
public String label() {
return "$Color$ $Shape$";
}
}
A tiny README is enough.
Suggested working order
Complete the following without copy-pasting the earlier lesson text line by line:
- create the project directory
- run
divekit initwith the distribution nameWS1 - create one tiny placeholder-based source file
- review
config.jsonso it points to your real host alias and your realgroupId— the default naming pattern already keeps the UUID visible - check with
divekit devwhich placeholders still need individualization, then scaffold the file withdivekit dev --write-individualization - review or refine
individualization.jsonso it containsShapeandColoras object IDs, each with its ownkinds - run
divekit devagain - run
divekit doctor - provide your test member with
divekit members, or enter it whendivekit distributeasks - optionally run
divekit distribute -d WS1 --provider local - run
divekit distribute -d WS1 - inspect
individuals.jsonandremotes.json - run
divekit overview -d WS1
Verify your result
Before you mark the exercise as done, verify all of the following:
divekit doctordoes not show a blocking setup problemdivekit devdoes not show unresolved placeholders you still need to define- if you used
divekit distribute -d WS1 --provider local, the generated local result looked correct divekit distribute -d WS1creates the expected repositoriesindividuals.jsoncontains every UUID you plannedindividuals.jsonrecords a concrete choice for bothShapeandColorremotes.jsonrecords every created remote repository- your test member is visible on the created repositories in GitLab
divekit overview -d WS1matches the visible result in GitLab
If one of these checks fails, do not start over immediately. Reuse the troubleshooting order from the previous lesson.
Check
config.json and individualization.json are the files you review and edit to define the rollout. State files such as individuals.json and remotes.json are generated by Divekit and record what the rollout actually produced.
divekit doctor is often the clearest answer because it reveals blocking setup problems before the real rollout. divekit dev adds confidence by confirming that placeholders are fully defined, and divekit distribute -d WS1 --provider local can show a realistic result without touching the real GitLab target.
individuals.json if the UUID seems linked to the wrong generated individual or the wrong variation choices. Inspect remotes.json first if the problem is which remote repository that UUID ended up in. In practice, checking both is often the fastest way to confirm the full mapping.
Shape or Color.
If all checks pass, you have completed the beginner course: from a plain project folder to a verified, individualized distribution.
Clean up
The exercise repositories have served their purpose — delete them from the shared GitLab instance:
divekit purge -d WS1
Divekit lists the repositories in the target group, shows a deletion plan, and asks for confirmation.
Remember the warning from the troubleshooting lesson: the plan covers everything in the target group, not only what this distribution created. Read it before you confirm — if it lists more than your WS1 exercise repositories, answer No and check which group you are targeting.