What MOVES, what DOES NOT, and WHAT THE USERS GET. The step people treat as A BUTTON and should treat as A RELEASE.
Publishing is one action and it is the moment your work becomes the thing other people depend on, which is a different category from every other action in this course.
WHAT MOVES IS THE APPLICATION DEFINITION: PAGES, FLOWS, CHAINS, VARIABLES, THE SERVICE CONNECTIONS AS CONFIGURED. Everything you built. It becomes the live version and every user who loads the application from that moment gets it.
WHAT DOES NOT MOVE IS THE DATA. Business object rows stay where they are — publishing does not copy them and does not delete them. Which is right, and it is also the thing people are surprised by when they expect a publish to reset something.
AND WHAT ALSO DOES NOT MOVE, WHICH IS THE DANGEROUS HALF, IS THE ENVIRONMENT-SPECIFIC CONFIGURATION UNLESS YOU MADE IT MOVE. Endpoints and credentials travel exactly as they are set — so a connection pointing at test still points at test after it is published. Lesson 10's first failure, and Lessons 5 to 7 exist for it.
WHAT THE USERS GET IS THE NEW VERSION, IMMEDIATELY, WITHOUT ASKING FOR IT. There is no installation and no opt-in — the next page load is the new application. Which is the advantage of this model and the reason a publish is a release rather than a save.
AND SOMEBODY IS ALWAYS MID-TASK. Half-completed forms, a flow somebody is three pages into — Lesson 2, and it is the part treating it as a button ignores.
SO THE MINIMUM DISCIPLINE IS THE MINIMUM OF ANY RELEASE: KNOW WHAT CHANGED, KNOW WHO IS AFFECTED, PICK A TIME, AND KNOW HOW TO GO BACK. None of that is heavy and none of it is done by the button — which offers no confirmation of scope, no diff and no warning about who is using the application right now.