Search: "deployment plan"

In the last sprint cycle, we focused on improving our deployment plan. On top of that, we made several improvements to the store.

Deploy - Architecture: The description users see when adapting the topic retention size has been changed to be less confusing. Deploy - Deployment plan: The algorithm for genarating a default deployment plan is improved to keep JMS downtime and alerting to a minimum. (#1009) Deploy - Deployment plan: A change in the memory settings of a container triggers a redeployment of the container. (#993) Deploy - Properties: We removed the deprecated tab Properties in the Deploy phase.

In the last sprint cycle, we focused on improving our deployment plan. On top of that, we made several improvements to the store.

====Minor changes==== * Design - Channels: Moving already attached channels in the flow designer has been made sligthly easier. (#845) * Create - Framework: The framework used in the flow designer has been updated, improving performance. * Deploy - Architecture: The description users see when adapting the topic retention size has been changed to be less confusing. * Deploy - Deployment plan: The algorithm for genarating a default deployment plan is improved to keep JMS downtime and alerting to a minimum. (#1009) * Deploy - Deployment plan: A change in the memory settings of a container triggers a redeployment of the container. (#993) * Deploy - Properties: We removed the deprecated tab Properties in the Deploy phase. * Deploy - Release properties: The description of a property can be changed by editing the property. (#1064) * Deploy - Release: The start/stop/restart machine deployment steps are now also executed correctly for AWS and on-premises machines. * Deploy - Release: When a release is removed, the related unused images in the on-premises machines will be removed as well. * Deploy - Release: Performance improvements have been implemented for loading releases in Deploy. * Manage - Alerting: If alerting has been paused manually, it will not be activated automatically after a release deployment. (#1024) * Manage - Alerting: Inactivated users should be removed from all alert settings (including “disabled“ settings) to avoid undesirable notifications. * Manage - Monitoring: Graphs showing problematic runtimes, queues and requests have been updated to be sorted by “Process CPU usage”, “Messages in queue” and “Unsuccessful requests” by default respectively for 3rd generation runtimes. (#1069) * Manage - Monitoring: The 3rd generation runtime dashboards have been changed to show data on UTC time zone by default. (#1070) * Manage - Monitoring: Variables in the 3rd generation runtimes HTTP statistics detail pages are now sorted case insensitive. (#1063) * Administration - My account: When an account password change request is made, even when this fails, a mail is sent to the account owner to inform on the action. * Administration - My account: When changing a password, it is compared to a list of known database breaches for security.

Including in this feature is a new deployment plan step to automatically balance all of your failover connectors based on your configuration. The old failover deployment step has been deprecated and replaced by the aforemention new deployment plan step. Please find out more here. Minor changes Design - Solution Design: When adding an integration to an existing API in Design, the pop-up now shows that a new integration is being added, instead of an existing integration being edited.

Including in this feature is a new deployment plan step to automatically balance all of your failover connectors based on your configuration. The old failover deployment step has been deprecated and replaced by the aforemention new deployment plan step. Please find out more [[here>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Grouping and Failover.WebHome||target="blank"]].

This microlearning will focus on configuring the deployment plan to control various inbound components in a typical group and failover configuration.

Key concepts == This microlearning describes how to configure (parts of) your deployment plan to set up the grouping and, if needed, the failover functionality.

The group name needs to match **exactly** to make it work. * You can control group and failover steps from the deployment plan. * Container inbounds can have a different failover status. == 5.

Prerequisites == * Basic knowledge of the eMagiz platform * Completed all microlearnings from Deploy till this specific microlearning * Have an environment where you can add releases and that is operational to try out the deployment plan == 2. Key concepts == eMagiz provides the capability to manage your deployments effectively so that all your updated flow components as created in the previous ILM phases of eMagiz.

Select the option set as active to make this the release that the deployment plan will use to deploy the updated, new, and changed flows.

Key takeaways == * The Release defines what is to be deployed on a specific environment, as compared to the Deployment plan that determines what is to be deployed * Use proper naming and clean your old releases regularly.

. (#1053) Deploy - Architecture: We have improved machine health calculations to prevent the creation of a machine with invalid memory configurations. (#1282) Deploy - Deployment plan: Users are blocked from being logged out during deployment execution, so that triggers are re-enabled after the deployment plan has been executed. (#1293) Deploy - Properties: Cron triggers now allow for hours, days and months prepended by a 0, for example 05.

. (#1282) * Deploy - Deployment plan: Users are blocked from being logged out during deployment execution, so that triggers are re-enabled after the deployment plan has been executed. (#1293) * Deploy - Properties: Cron triggers now allow for hours, days and months prepended by a 0, for example 05. * Deploy - Releases: Users are blocked from deploying at the same time on the same environment on the [[current runtime>>doc:Main.eMagiz Academy.Fundamentals.fundamental-runtime-generation3||target="blank"]] architecture. (#1293)

Key concepts == {{warning}}Regardless of what your change entails you always need to execute the deployment plan to deploy and actualize the changes on your environment.

Once you have created your new release, you can use the deployment plan steps to activate the changes on both flow and property levels. More information on how to do this can be found in this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-execute-deployment-plan-gen3.WebHome||target="blank"]]. == 4.

. (#785) Store: Renamed several display names across the Store functionality to better clarify what the functionality does for you. Deploy - Deployment plan: For 3rd generation runtimes we have changed the restart behavior in case of startup problems.

Bug fixes Create - Flow designer: Resetting the JMS server sometimes resulted in invalid connection settings for connecting to the failover JMS server. (#717) Create - Flow designer: Newly generated flows were configured with incorrect XSD or XLST resource locations under specific circumstances. (#718) Deploy - Deployment plan: Before when you tried to deploy a Release via the Deploy functionality the widget could crash randomly.

. (#785) * Store: Renamed several display names across the Store functionality to better clarify what the functionality does for you. * Deploy - Deployment plan: For 3rd generation runtimes we have changed the restart behavior in case of startup problems.

====Bug fixes==== * Create - Flow designer: Resetting the JMS server sometimes resulted in invalid connection settings for connecting to the failover JMS server. (#717) * Create - Flow designer: Newly generated flows were configured with incorrect XSD or XLST resource locations under specific circumstances. (#718) * Deploy - Deployment plan: Before when you tried to deploy a Release via the Deploy functionality the widget could crash randomly.

. (#1100) Deploy - Containers: The collection and publishing of runtime metrics is no longer synchronized across containers, which improves their processing. Deploy - Deployment plan: We solved a bug where a deployment step in the deployment plan could randomly get stuck.

. (#1100) * Deploy - Containers: The collection and publishing of runtime metrics is no longer synchronized across containers, which improves their processing. * Deploy - Deployment plan: We solved a bug where a deployment step in the deployment plan could randomly get stuck. * Deploy - Runtimes: We improved the out of memory behavior of runtimes.

For more information on this please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-execute-deployment-plan-gen3.WebHome||target="blank"]]. ====New features==== New components to support a failover setup: * Clustered lock registry: obtain a lock that can be shared over different containers * Leader initiator: Used to automatically start and stop roles based on whether they can obtain a cluster-wide lock * New & extended operations for controlling integration components ** New: Start & stop all components in a specific role, so you can start and stop multiple components at the same time ** New: List all roles and whether they support leadership ** Extended: List flow components now also shows whether a component is configured to be in a role Deploy - Deployment plan: to incorporate failover actions during deployment, two new deployment step types are introduced namely “Group” and “Failover”. )))((({{toc/}}))){{/container}} {{/container}}

Prerequisites == * Basic knowledge of the eMagiz platform * Understanding Releases and be able to run a Deployment plan effectively * Understanding Containers and how flows are managed across them == 2.

If you want to know more about when a new image is created for a container, please read this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-execute-deployment-plan-gen3.WebHome||target="blank"]]. ** Note that this can be **red** in case the latest changes are not deployed on the certain runtime. For example if your deployment plan stops half way and there were changes which need to be deployed in the second part, you could end up in this situation. * State ** Throughout the lifetime of a container it can have one of the 6 states mentioned below.