Chapter 18
The Deployment Hub
After the twentieth time typing the same publish commands, I built a small dashboard to do it for me. Here is why, how it works, and a working demo of it.
Pega 24 – 26
Words you will meet
- Publish
- Stepper
- Queue
The story
Why I stopped typing commands.
Publishing a component is a short recipe: sign in, build, check, send. Done for one component on one server it is fine. Done for a dozen components, across a development and a test server, with different ruleset versions, it turns into copy-pasting commands and editing a settings file between each one. It is easy to publish to the wrong place.
So I put a face on it. One page where you choose where, tick what, and press a button. The same builder still does the work underneath. The hub only fills in the answers and shows the result clearly.
Play
A sneak peek.
This is a demo with invented servers and components, not the real thing and not connected to anything. Pick a place, tick a few components and publish. Publish the same ones again and watch it become a Republish.
- Validate
- Lint
- Bundle
- Package
- Publish
Goes to Dev · DemoComponents 01-01-02. Simulated: nothing is sent anywhere.
Press Publish to see the output here.
Under the hood
How one run works.
- 01You press PublishThe page sends the action to a small local server running on your laptop.
- 02It writes your settingsThe server puts the chosen server, ruleset and version into the project settings file.
- 03It starts the builderThe normal builder command runs with every answer it would have asked for already filled in.
- 04Output streams backEach line reaches the page as it is printed. The stepper and the terminal move together.
The anatomy
What is inside.
- server
- Serves the page and its small API. Started with one command.
- api/
- One file per job: environments, sign-in, components, running the builder, reading its output, stopping a run.
- web/
- The page itself: plain HTML, one stylesheet for light and dark, and one small module per part.
- test/
- Automated checks for the trickiest logic, such as the order of a multi-component publish.
What I learned
The careful parts.
Secrets stay on the laptop
Sign-in secrets can be written but never read back by the page, can come from an environment variable instead, and live in files Git ignores.
It reads between the lines
Some failed sign-ins end quietly with a success code, so the output is read for what went wrong and shown in plain words.
One bad component stops the queue
Publishing several stops at the first failure, unless you say to carry on. A problem with the target, such as a locked ruleset, always stops it.
Republish is recognised
Publishing the same thing to the same place twice is shown as a Republish, with its own history.
Stop is honest
Stop ends the running component and the rest of the list. What already reached the server stays there, and the message says so.
Use it
Get it for your own project.
The hub is a free package you can add to any Constellation components project. Install it from npm, or copy its files into your project and change them however you like.
Node 20 or newer
Check with node -v.
A Constellation components project
One that already has the builder installed and a project settings file.
Storybook with Vite (optional)
For the page inside Storybook. The standalone command needs no Storybook.
# Option 1: install it, and set the project upnpm i -D @sanjeevsaniel/dx-deployment-hubnpx dx-hub init # Option 2: copy the source into your project and make it yoursnpx @sanjeevsaniel/dx-deployment-hub eject # Then copy hub.config.sample.json to hub.config.json# and fill in your own servers (Git is told to ignore it). # Run it on its own...npx dx-hub# ...or add it to Storybook and open /hubPrefer a file to download? Each release has a zip with the package and the install steps. The code is on GitHub, where you can read it and report a problem.
Your turn
Questions and comments
Stuck on something, or have a thought? Write it here. To talk about one part, use the Comment button under that section's heading.