A VetCoreSolution® release is ready… what happens next?
Before reaching a veterinary practice, every release passes through five control stages that let us prove its origin, contents, and the tests it has passed.
Pierre Bony
President, co-founder and CTO
Do we simply copy a few files onto a server? Not quite.
At VetCoreSolution®, deployment means sending one precise release through a chain of controls while remaining able to prove where it came from, what it contains, and which tests it has passed.
The journey has five major stages.
The code for each component — web applications, servers, and services — is first containerized separately. Like a shipping container, every image is standardized, sealed, identified, and portable from one environment to another without changing its contents.
Stage 1 — Code does not come aboard unchecked
Every proposed code change automatically triggers a battery of tests.
We will return to testing in a future TechNote: the subject easily deserves an episode of its own.
Stage 2 — Building and identifying the containers
When a new release is declared, our continuous integration pipeline — the automated factory that creates releases from code — builds the corresponding images.
It then stores them in our container registry: our digital shipping terminal. Each image is stored, identified, and ready to deploy. Its metadata lets us trace the exact release and the code that produced it.
The image also receives a digital signature with Cosign. Our environments can therefore verify that it genuinely came from our build pipeline and that it has not been replaced or altered.
Stage 3 — “Latest” does not mean “production”
Every new image first receives the “latest” tag. For us, that means: this is the newest release to be put through its paces.
Every night, the “latest” images are deployed to servers reserved for validation, also known as clusters. Tests run throughout the night to observe the platform’s behavior, stability, and performance.
Stage 4 — Promoting without rebuilding
When the results are satisfactory, we do not rebuild a new image. We take the exact image that passed the tests and promote it by assigning the “prod” tag.
For the more technical reader: its digest does not change. It is strictly the same content, now authorized to move into production.
Stage 5 — The final deployment
On demand or during an overnight campaign, our delivery pipeline orchestrates installation on the production server cluster. It verifies that services start correctly, the platform responds, and the final checks pass.
Only then is the new release made available.
Why go through all these stages?
Because we must be able to answer three simple questions at any time:
- Which code is currently running?
- Which image is carrying it?
- Which checks has that image passed?
