What PDM is

PDM (Platform Development Manager) is an internal system that shows every platform environment in one place: which ones exist, what is deployed on them, whether they are up right now and what has been done to them lately. Application builds and configuration rollouts are started from here as well.

What problem it solves

The platform does not run as a single copy. There are test environments, demo environments and production ones — each with its own set of application versions and its own settings. Without a single place to look, it plays out like this:

• nobody is sure which version of an application is currently deployed on a given environment;
• environment settings quietly drift apart, and "works on mine" stops meaning anything;
• updating the same thing on several environments means repeating the same steps by hand;
• finding out who deployed what and when means digging through the build system's history;
• when an environment goes down, you hear about it from whoever hit it first.

PDM removes that legwork: all of the above lives on one screen.

What PDM gives you

• A list of every environment. All clusters and environments with a state indicator on each. In PDM an environment is called a stand.
• Stand settings in a readable form. Parameters are grouped by application, and you can see where a value is shared across all stands and where it is set for this one.
• Builds and deployments. Building an application from a branch and putting the result on a stand is done straight from the interface.
• Releases. A single agreed change of settings and versions is rolled out to many stands at once.
• Progress of long operations. Every long operation is broken into steps, so you can see where it is now and where it failed.
• State and availability. Stands are polled regularly; each has a current status, uptime over a period and a history of status changes.
• History. Releases, builds and started operations are kept, so you can go back and see what happened.

Mirror and remote control

Mirror. PDM itself stores almost nothing. Clusters, stands, current setting values and secrets all live in external systems; PDM reads them regularly and displays them. What you see on screen is a snapshot of those external systems, refreshed by synchronisation.

Remote control. PDM does not apply changes locally either: it triggers them in the external systems — writes settings into the configuration storage, starts a build, applies the configuration on a live environment. The result comes back to the interface with the next synchronisation.

Why this matters

Two practical rules follow from this. First, if a stand is deleted in the cluster, it disappears from PDM too — the data follows reality, not the other way round. Second, time can pass between an action and its effect showing up in the interface, so you follow an operation on the operation's own page rather than in the settings list.

Systems PDM is connected to

External system	What PDM reads from it	What PDM sends to it
Kubernetes clusters	the list of clusters, projects and stands, the state of running applications, secrets	applying a new configuration on a live environment
GitLab	current stand setting values and shared defaults, application branches and versions	triggering builds, writing changed settings

PDM shows links to GitLab pipelines right inside the operation's steps, so you can always drop into the original system and look at the details.

Data refreshes itself

There is no need to reload the page: stand statuses and the progress of running operations reach the browser on their own as they change.

Who it is for

• Testers — see which version is on a stand and ask for a particular branch to be deployed.
• Developers — build an application and put the build on their own stand without opening GitLab.
• Analysts and managers — see what is deployed where, what state the stands are in and what went into the last release.

What is available to you depends on the permissions you were granted: buttons and sections you have no rights for are simply not shown. Permissions are granted by an administrator — see Permissions.

What's next

• Core concepts — cluster, stand, configuration, release and the rest of the system's vocabulary.
• Capabilities — what the system can do, block by block.
• Signing in — where to start.