Question: How do we "isolate" our
# generalt
trentc
10/31/2024, 3:15 PMQuestion: How do we "isolate" our development activities from Production?
trentc
10/31/2024, 3:16 PMRight now, I'm just in development stages. So, when I move to a tested, validated, and stable solution within UMH I would "promote" it to "Production"
Once I'm in production, and I need to add new features or data.....how whould we isolate the development so to avoid impact on the stability of production?
trentc
10/31/2024, 3:19 PMOne might follow a workflow of
1. Development (DEV) - Active changes being made, no access to change production data, or manipulate device values that have already been validated.
2. Quality Assurance (QA) - Production release candidate, No more active development, just testing for bugs and stability
3. Production (Prod), tested and validated, no active development, now fully integrated with all data sources and stores.
j
Jermuk
10/31/2024, 3:20 PMThe discussions comes from our current thoughts abotu having multiple release channels:
1. Stable
• Access: Community members.
• Purpose: Provides the most reliable and tested versions for general use. Excludes theversion checks (e.g., for the OS) that are considered annoying for a lot of community members)
2. Nightly
• Access: Internal use by the development team.
• Purpose: Hosts the latest updates and features for testing before they are deemed stable.
3. Enterprise
• Access: Enterprise customers only.
• Purpose: Tailored for enterprise environments with additional production checks and specific requirements (e.g., enforcing that oen uses either Rocky or flatcar)
Release Workflow
1. Initial Release:
• New updates are first deployed to the Nightly channel.
• This allows for rigorous testing on production servers alongside automated tests to identify and fix issues early.
2. Stabilization:
• Once the development team is confident in the stability and performance of the new update, it is promoted to the Stable channel.
• There is a typical delay of about a week before the Enterprise channel receives the update, ensuring that enterprise customers benefit from the latest stable features after thorough validation.
From this on we started to discuss how one can setup "Development, QA, and Production Instances":
one can setup instances like this and ultiize bridges to share data between instances without impacting production devices. Managing multiple instances fetching data from the same PLC can lead to failures.
I also know that one customer of us is doing something similar, so maybe @Mateusz can share his thoughts / the customer thoughts on this?
t
trentc
10/31/2024, 3:25 PMRight now, there isn't an easy way to enable/disable connections or protocol converters.....so it's not practical to have multiple instances of UMH with identical configuration...causing redundant connections and data flow conflicts....
This might require "decoupling" of the data source and data store.
The data store can be relatively easily isolated by having a 2nd instance of UMH....
The data source though.....maybe UMH Lite, or a 3rd instance of umh classic that acts as a "data source" to both of the other instances (DEV and PROD) through a bridge? UMH Lite already bridges the data sources via MQTT...
trentc
10/31/2024, 3:27 PMMigrating grafana to grafana or node-red to node red, or timescale to timescale isn't too bad....they each have their own workflow migration procedures that could be put i place....
However, UMH connections, and DFCs.....currently doesn't have an "exposed" method to migrate them
j
Jermuk
10/31/2024, 3:30 PMthis is actually haflway exposed, its the mgmtcompanion-config
t
trentc
10/31/2024, 3:31 PMIf you take a look at an example from tatsoft....they have a feature for "execution profiles" to quickly switch between.
trentc
10/31/2024, 3:31 PMtrentc
10/31/2024, 3:34 PMIs it technically possible to use the management console to automatically "migrate" from one instance to another?
Dev-Instance -> Prod-Instance
With the ability to "revert"?