Software Distribution Hub is a platform that simplifies the packaging, versioning, and delivery of your software products. By using it, you can manage your software release across multiple clients (tenants).
Devtron's Software Distribution Hub is designed to be used in scenarios where:
Tenanted deployment: You build software solutions for clients (tenants) who require updates deployed to their distinct environments. For every tenant, you may have to deploy a separate instance of your application, which has separate application layer and data layer on their infrastructure.
Complex Release Management: You need a centralized solution to manage the deployment of software updates across various environments and ensure smooth collaboration between different teams involved in the release process.
Poor Visibility and Monitoring: You need improved visibility into the release process for stakeholders such as Release Managers, Developers, DevOps teams, System Reliability Engineers (SREs), Tenant Points of Contact (POCs), and other stakeholders. They need to monitor releases, debug issues, and have access to current operational statuses.
Inconsistent Deployment Processes: You need standardization because you face operational challenges and deviation in your release outcomes, while carrying out deployment processes across multiple tenant environments.
Insufficient Release Documentation: You intend to eliminate confusion because your releases lack detailed documentation, including versioning, dependencies, configuration changes, and deployment prerequisites, causing inconsistencies and deployment failures.
Devtron's Software Distribution Hub goes beyond basic deployment by providing end-to-end release management. Deployments involving manual processes might be prone to human error. However, Software Distribution Hub streamlines the rollout process by enforcing requirements for each release, and not just for one environment but multiple tenant environments.
Devtron's Software Distribution Hub has 2 sections:
Feel free to familiarize yourself with the following concepts (terms) before you proceed to Software Distribution Hub.
Tenants are organizations or clients that use your software. You can think of each tenant as a separate customer. For example, if Microsoft and Google both use your software, they are considered separate tenants. Each tenant has its own environment to ensure their data and operations are kept separate from others.
One installation represents one deployment of your software for a specific tenant. Each installation serves as a separate instance of the software, customized for different stages of use or separate teams within your organization. For example, your organization might have three installations:
Production Installation: Where the live environment of the software runs for all your end-users.
Development Installation: Used by your team of developers for testing new features and changes before they go live.
QA Installation: Dedicated to quality assurance (team of testers) to ensure the software works correctly before it reaches users.
A Release Track in Devtron is where you organize software releases. Each release within a Release Track is a unique version of your software. For example, think of Kubernetes as a release track, with "v1.28.8" as one of its releases. This helps in managing different versions and updates of a software project in a structured manner, ensuring that all versions are tracked and organized within their respective tracks.
Requirements refer to specific steps that should be taken before deployment of applications. This includes selecting specific images for each application, specifying the release order of applications, adding release instructions, and locking these requirements to ensure readiness before a rollout.
This is a part of requirements where you decide the stages in which applications are deployed to ensure all dependencies are met. For example, you might need to deploy a backend service before a frontend feature that depends on it. In such a case, release order ensures that backend applications are deployed in the first stage, followed by frontend applications, ensuring a smooth and coordinated rollout.
It is a process of delivering a new release to the tenant's environment. In Software Distribution Hub, this comes right after you lock the basic requirements of a release (i.e., application selection, release order, image selection, and release instructions).
This section allows you to add new and map environments to these to ensure updates correctly.
This involves the creation of new organizations where you wish to deploy s/w updates. Whenever you are onboarding a new client, you add them as a tenant.
Click + Add Tenant.
Enter a name in Tenant display name field, e.g., flareup.xyz. Once set, you can rename it later (if needed).
Add a unique identifier to your tenant in Tenant ID field, e.g., flareup123. Once set, you cannot change it later.
(Optional) Add a description of the tenant.
Click Save.
Click the tenant you created.
Click + Add Installation.
Enter a name in Installation display name field, e.g., Flareup Prod
Enter an Installation ID, e.g., flareup-prod-1
Click Save.
Click Map Environment.
Use the checkbox to choose the environments to map to the tenant installation. Note that, you cannot map an environment that is already mapped to another tenant installation.
Here, we have mapped doc1 and doc2 environments to the production installation.
Click Save
| Aspect | Normal Deployment | Software Distribution Hub |
|---|---|---|
This involves setting up for different environments, such as Prod, Development, and QA environments. You can consider these as licenses/installations your client has subscribed for.
This involves mapping customer's environments to the tenant installation so that your updates are deployed to the correct environments. If you haven't created an environment yet, refer .
Next, you need to set up a release on . If you have correctly mapped the customer's environments to an installation, and if you choose applications that already have those environments (say doc1 or doc2 or both) in their deployment pipeline, you can your release.
Release Management
No versioned deployments
Centralizes versioning and deployment into a unified platform
Visibility
Limited visibility
Comprehensive visibility
Automated and Standardized Deployments
Relies on manual scripts or basic automation (jobs)
Automates and standardizes deployments for consistency
End-to-End Release Management
Focuses on pushing changes quickly
Manages entire release lifecycle from planning to post-release
Collaboration
Gap or siloed communication among teams
Facilitates collaboration among developers, release managers, and other stakeholders
Create a Tenant before proceeding with any action in Release Hub.
This section allows you to define release tracks, create and version software releases, add applications, select container images, and deploy releases to specified tenant installations.
This involves the creation of release tracks and software versions. A release track helps you organize and keep track of different versions of your software. So if you ship multiple products (say HRMS, Web Builder, Video Editing Tools), you can create separate release tracks for each.
Click + Release Track.
Give a name to the track, e.g., numero
(Optional) Add a description of the track.
Click Create Release Track.
Click + Create Release.
Select a track (e.g., numero) from the Release Track dropdown.
Enter a semantic version in Release Version field, e.g., 1.0.0
(Optional) Give a name to the release, e.g., numero-beta. If you don’t provide one, the name will be same as release version (i.e., 1.0.0).
(Optional) Add a description of the release.
Click Create Release.
If you are creating your first release, you may proceed with the Create from scratch option. However, for subsequent versions of your release (say 1.0.1), you may clone an existing release (e.g., 1.0.0) as shown below. Please note, you can only clone releases belonging to the same track.
This involves the inclusion of applications you wish to rollout in the release version created by you.
Click + Add Application button present within the release you created.
Click the Search and add applications dropdown.
Use the checkbox to add applications from your projects.
Click Add Release Stage.
By default, your selected applications will be set to release in one go. However, you can also release them in stages. In other words, you can decide which set of applications should be released first, subsequently which ones to release next, and the ones to release last. For example, if you're adding a new payment system (backend) and an updated checkout page (frontend), you would release the payment system first to ensure payments can be processed correctly.
Use the drag-and-drop feature to move applications from one stage to another.
The drag-and-drop feature is designed specifically for moving applications between different release stages. It is not meant to alter the sequence of applications within the same stage.
Once you have finalized the sequence and stages, click Save Changes.
Select a workflow available for your application. All the images available in the selected workflow will appear.
Only the images that were built already will appear. If there are no images present, trigger the CI pipeline of the application first to obtain the image.
Click SELECT next to the image you wish to deploy from the list.
Repeat the above steps for other applications you added in the release.
Click Save.
You may add release instructions for each application using the in-built Markdown editor. This can be detailed deployment notes and configuration guidelines for the team.
Before locking the requirements, make sure the release order is correct, add applications if needed, and include environments in tenants (if not done already). Once you have finalized them, click Lock Requirements.
Once you lock the requirements, Devtron will prevent any unsolicited modifications to your release by anyone (including you). However, you can re-edit it by clicking Unlock To Edit.
All your requirements need to be locked and tenants must be configured.
This involves the deployment of the release to the specified tenant installations.
Go to the Rollout Release tab.
Your release needs to be marked as ready to proceed further. If it isn’t, you can mark it Ready for release from this screen.
Optionally, you can also do so by changing the status from Draft state to Ready for release within your release track.
Use the checkbox to select the applications belonging to the first release stage. You may use the filters on the left-hand side to make it easier.
Click Deploy.
If the application workflow has pre-deployment/post-deployment stage, you get a dropdown where you can specifically trigger either pre-deployment, deployment, or post-deployment stage.
Once the applications from the first release stage are successfully deployed, select the applications from the subsequent release stage and deploy.
An application can be deployed on the tenant in the next release stage only if other applications in the previous stage are deployed successfully on the given tenant.
Here we covered the process of performing a production installation on just one tenant. Similarly, you can perform installations on your other tenants (if any).
You can view the status of your release at a particular tenant under Rollout Status. Moreover, you can go to Rollout History tab to view the deployment history.
You can view the following statuses
Apart from the rollout status, you can also see the release status:
If the applications are partially released, the release status shows Partially released.
If all the applications in a release are successfully deployed, the release status shows Completely Released.
Alternatively, you can view the release status directly in the release track too.
If a release is put on hold, none of the applications (in any release stage) can be deployed in that release.
When to use:
When a release was marked as ready, but is still not ready for deployment
If issues are found during pre-deployment checks
When waiting for approval from stakeholders before proceeding
Why to use:
To prevent the release from being deployed prematurely
To allow time for additional testing, review, or completion of necessary tasks
To ensure that all requirements and dependencies are met before deployment
When a release is rescinded, it is marked as invalid or buggy, and cannot be used for further deployments. This action ensures that that the release cannot be modified further and no applications within the rescinded release can be deployed. However, deploying from the Build & Deploy page of Applications or Application Groups will still be possible.
When to use:
When a release is found to be buggy or has critical issues
If the release does not meet the required standards or specifications
When a decision is made to cancel the release entirely
Why to use:
To ensure that faulty or incomplete software is not deployed
To maintain the integrity and reliability of the software environment
To provide a clear indication that the release is no longer valid and should not be used
In the Overview section, you get a Markdown editor to add release notes. You can add text, images, links, and many more to clearly communicate updates and changes in each release. This keeps everyone informed and might contribute to a smoother deployment process.
Based on the schema provided in the catalog framework, you can add relevant details for release. Refer Catalog Framework for more details.
| Rollout Status | Description |
|---|---|
All Tenants
Overview of rollout status across all tenants installations
Yet to Trigger
Shows tenant installations for which rollout has not yet started
Ongoing
Shows tenant installations for which deployment is currently in progress
Failed
Shows tenant installations where rollout has encountered issues because some deployment stage failed
Completed
Shows tenant installations where deployment has successfully finished and services are live
