Low-code development teams spend a considerable amount of time and energy on scoping and developing the next set of features for their low-code applications. Developing robust apps that deliver the expected outcomes is of the utmost importance. But the process of moving the application from a development environment, through a test environment, and into a production or live environment is too often an afterthought.
Having a well-established and well-communicated plan for releasing an application to a production environment is the single most important part of a go-live. Here are a few items you should think through before you do any release:
-
When is the release going to start, and how long will it take?
Work with the stakeholders to identify a time when they will be minimally impacted. The duration is hard to predict — the more you do it, the better you’ll be able to estimate this. Underpromise and overdeliver on your estimate.
-
How are the end users going to be impacted during the release?
No matter how well you communicate releases and planned downtime in advance, you have to assume a user will be in the application if they can be. This might not be a problem, but if it is, you might consider prohibiting access to the application during the maintenance period.
-
Who is responsible for each step of the release process?
A detailed plan should be socialized with the team of people who are performing the steps. Take the time to review the plan together, and emphasize that there are no dumb questions when it comes to clarity on the release plan. Make sure each individual has the correct access to perform the steps he/she is assigned to do.
-
What new connections/integration points to third-party applications are being introduced?
The first time a connection or integration is going live, there will be a little uncertainty in the back of the team’s mind. An incorrect API key or blocked network traffic could throw a wrench in the plan. Developers should make it a point to call this out for the team so the new connection can be appropriately planned for.
-
If the release is not successful, what is the backout plan?
This is never the expected nor desired outcome, but having a plan ahead of time will guide the team during a stressful situation.
You only get one chance to have a successful go-live on the first try. I suggest using a test or staging release as a dry run for production to work out any issues.
When it comes to the Jitterbit App Builder application releases, your developers create a release from the development environment, download the release file (we call it an LP file), and upload it into the target environment to be installed. There are a couple of common risks you should double check before you create the release and install it into production:
-
Table install options:
More often than not, you’re going to have physical tables included in your release. Each table has an install option setting which determines how the data stored in the table is handled when the release is created, and subsequently installed, in a target environment. This is a powerful capability, yet it should be used cautiously. You definitely don’t want to replace quality production data with all the data developers create. You can find out more about these options on our Build a release package documentation page.
-
Roles:
Access to a page, as well as the native create/edit/delete capabilities of data shown to a user on a page, is granularly controlled in the logical layer. Any time a developer modifies the roles of a business rule or introduces a new business rule to a page, it may have an unintended effect on a particular user group’s ability to get to the page. Creating a test user for each user group and regression testing for roles is a great practice before any release into production. This will help you avoid the dreaded “I can’t get to this page anymore” email from your end user the day after a release. Check out this documentation page for more information on privileges and permissions.
Each time you go to release your Jitterbit App Builder application, scrutinize the release template. You should only release the components of the application that have changed and that you want to release to production.
In your release template, you can choose these different components. You, of course, can release an entire application that will include all the data sources, logic and pages. Or if your change was on a smaller scale, you could release just a single page or single business rule and release those smaller components to production, leaving the rest of the application as is. This flexibility in the release process allows your development team to more easily respond to any critical issues that come up while working on the larger requests.
The application component feature enhances flexibility, speed and control over the software deployment process, making it a powerful tool in environments that require frequent updates and minimal downtime. The key benefits of for your development teams are:
-
Modular Updates:
Allows specific components of an application to be updated independently, reducing code dependencies.
-
Minimized Downtime:
Only the changed components are updated, enabling smoother upgrades.
-
Greater development agility:
Teams can release updates or patches quickly for individual components, boosting response time.
Learn more about Jitterbit App Builder, or the powerful suite of AI features coming soon to App Builder 4.0.
