Developer forum

Anybody?

Am I the only one trying to implement this scenario?

Thank you,
Adrian

Hi guys,

Can anybody give me some guidance here?

I have managed to convince my customer to pay for the staging license but I am not sure how I can better take advantage of this setup.

For example, we need to implement a new website. Should I start the implementation on the staging version? Can I move the implementation to live instance afterward?

Are there any limitations to this scenario?

Thank you,

Adrian

Hi Adrian,

Here's the configuration that I recommend in many situations:

Often times I find that there tend to be two ERP environments: Dev and Production. If there are more that are actively used, then the plan above can change.

I also like to have at least Dev and QA web environments before production. This enables the QA environment to be as close to production as possible, with just the new features in QA. Once those changes are signed off, the QA environment can be pushed to production without having to pick and choose. 

Since there are often 2 ERP environments, but 3 or 4 web environments, the web environments can share an ERP environment (like in the table above).

You mentioned the possibility of starting by pointing the web environment to Dev and start to migrate the endpoints to production. While we've done that in some situations, you introduce some risks on orders being placed into production that aren't really production orders, or having unexpected test data, So, keeping a clean separation is usually best.

As for how to deploy the changes, the Deployment Tool is coming along nicely and works well, with some considerations.

• Data Integration jobs: They are the easiest since they are usually identical between environments, so you can start them in the Dev web environment and push them with the deployment tool to QA and eventually production.
• Scheduled tasks: These are more difficult because they differ between environments. At least the URL and secret should be different, and you may have other differences. For that, use the new Endpoint Management to parameterize the settings. It was introduced in 9.7 and enhanced in 9.8. Additionally, in 9.8, you can save the scheduled tasks as xml files that are even easier to deploy. That will enable you to have the different environment settings pulled out of the scheduled task.
• Live integration settings: Like scheduled tasks, they will have some environment differences. Use Endpoint Management for that.

I'm happy to explain more or give you a demo. We've been improving this over the years and it gets better with each pass. In fact, we're now starting to use Azure DevOps for the integration deployments and it's amazing, but it will be a few months before we have it perfected enough to share the details. The end-goal, and what we're just starting to do now, is that we simply check-in changes to Git, and they are automatically pushed to a Test environment. Once approved, they are pushed to QA. And when approved again, they are pushed to production. All with a trustworthy automated process and a click of a button, so it's predictable. But, I'm getting ahead of myself. The Deployment Tool is the easy way to get up and going, and it works well.

Scott

Hi Scott,

Thank you very much for the details. They are very useful.

I will try to apply it to my scenario.

Thank you very much.

Adrian

Hi Adrian,

You're welcome. 

Note that not just integration will need to deploy through the environments, so there will be other considerations too. As a general rule of thumb, you can use Git and a file-based deploy for everything to do with files (not images), and consider the deployment tool for other types of setting and data deployments.

Scott