MSAMM
Back to course

Oracle Visual Builder: Applications That Outlive Their First Release · Module 14 · Source control, environments and publishing

Branching and more than one developer

Lesson 140 of 176 · 3 min

Working in parallel WITHOUT OVERWRITING EACH OTHER, and what A MERGE CONFLICT LOOKS LIKE IN A VISUAL TOOL. Two developers in one application is where the underlying files stop being an implementation detail, and it is worth understanding before it goes wrong rather than during. THE FAILURE WITHOUT BRANCHES IS THE OBVIOUS ONE AND IT IS SILENT. Two people editing the same application, and one set of changes replaces the other with nothing reporting it — Lesson 10's fourth failure, and the person whose work is gone finds out by opening a page they finished yesterday. BRANCHES SOLVE IT THE SAME WAY THEY SOLVE IT ANYWHERE: EACH PERSON WORKS ON THEIR OWN, AND MERGING IS AN EXPLICIT STEP THAT CAN FAIL VISIBLY. Which is exactly the property you want — a merge conflict is a problem announcing itself, and it is enormously better than a silent overwrite. WHAT A CONFLICT…

The full lesson is part of the course

The video, the complete written lesson and the module quiz are included in Oracle Visual Builder: Applications That Outlive Their First Release, with a certificate on completion and a fourteen-day refund window.

See the course and enrol9 free lessons

Get the free lessons by email

We will email you a link to every free lesson in this course. No account needed, and one message only.

In this module: Module 14 · Source control, environments and publishing

  1. 1What a publish actually doesFree preview
  2. 2Versions, and living with two
  3. 3Source control, and why a visual tool still needs it
  4. 4Branching and more than one developer
  5. 5Environments, and what differs between them
  6. 6Making endpoints configurable
  7. 7The promotion checklist
  8. 8Rolling back
  9. 9Automating it
  10. 10What breaks: four promotion failures
  11. 11Lab briefing · Promote and prove it is isolated