Blue Prism Environment Configurations

[john.hammond]

Good Morning all.

Our team are currently in the stage of planning a new environment with a newer release of Blue Prism than we currently operate on (we are currently running v6.6, looking at v7.1). This is the first environment we have worked on which was initially set up for us by an outside party, and there have been a few issues that we have noticed - the Dev database is set up on a Test server, which has caused a number of issues, and we are also unable to use runtime resources within our Dev environment, which would have been useful for testing. Finally, we don't have a suitable 'test' environment to work on developing objects for APIs, for example, without cluttering the existing Dev database.

Because we now have full control over what our new environment will look like, we're looking for suggestions and thoughts on what other teams/individuals' environments look like. What would you consider to be a good environment? 

Our initial thoughts are running a Production - Live and Production - Development environment running on separate servers, and an isolated Pre-Production Testing environment for testing patches/upgrades etc. Unlike our initial setup, we would also have runtime resources communicating with our Production - Development server. One thought that we're having is to also have a Production - Testing environment, for UAT cases, but we're unsure whether there is a sufficient use case for this and feel it might become an overhead. Do any other users here have a similar setup? Would you mind explaining how you've gone about this, and the relevant pro's and con's for this. One particular question we have is the benefit (or lack thereof) of using a Production - Testing environment. 

All thoughts and feedback welcome! It's difficult to know what to ask for in terms of infrastructure when I've become so used to our existing one!

------------------------------
John Hammond
------------------------------

[R__BrentSwigert]

Hi John,

Our current environment is what we call a 3 tier configuration of Sandbox, T&D and Production. Production has its own isolated database server, application servers and load balancer as well some shared runtime resources(between production and T&D). Sandbox and T&D share a database server but they are on individual instances as well as independent application servers. The runtime resources are shared between these two tiers. 

This allows us to fully develop/test in Sandbox a variety of things while protecting the other platforms including any Blue Prism version upgrades. We can then promote those items to T&D for Prod Supp testing before moving them on to production. We've also segmented our network with vlans for each tier, not necessarily much gain from it but something implemented by our network team.

We've followed the same approach through data center migrations. This has allowed us to fully test all aspects of moves, upgrades, enhancements before production is touched. It may seem like overkill but if you have the opportunity to separate your environments you reap protection and benefits. We averted a major incident having this configuration. 

Good luck and if you have any questions please let me know.

Brent Swigert
Ascension Technologies, Enterprise Ideation & Automation

------------------------------
R. Brent Swigert
Digital Workforce Architect
Agilify Automation
America/Indiana/Indianapolis
------------------------------

[john.hammond]

Thanks for your response Brent - that all sounds very much along the lines of what we're currently thinking also. What you refer to as the Sandbox environment is something we don't currently have but definitely see the benefits of patching, upgrading and generally trying out new things. Just out of curiosity, with the ideal scenario being an identical Development resource to the intended Production resource, do your team essentially take 'ownership' of a particular Development resource (which could be different in terms of software installed etc. to certain prod machines) or do you develop on a 'mirror' of the particular Production machine that a process will currently run on?

------------------------------
John Hammond
------------------------------

[Walter.Koller]

Hi,

We have in house SW development with support of full SW dev lifecycle, ie dev, FAT, UAT, prod environments.
For BP development we decided to simplify the lifecycle process with only dev, pre-prod, prod environments.
We skip FAT and UAT. Pre-prod means we run the process in production environment but it didn't get the official 'in production' tag yet. The first step of pre-prod is the acceptance test with business (the equivalent of UAT) and being strictly monitored by our operations team and business for the first weeks. 
We only have 'production like' data in our UAT environment that would need special preparation to ensure it covers the scope of our process. Since we don't have IT projects for each of our process and our release cycles are much shorter than such projects, we decided for a pre-produdction approach.
The dev workplaces for our developers are located in the FAT environment.

Technically, we have two servers: production servers (1 app, 1 DB) and non-production server (1 app, 1 DB)
Each set of servers is located in its own network segment, but for us this does not matter. We cannot directly access the other environment (dev<>prod) but we don't have to anyways.
Each of the server runs several instances of BP with different purpose and required by GDPR.
Each production instance of BP has its own dedicated BP dev instance.
We also have an additional BP instance on our dev server, we call Training Environment. There are basically no restrictions in this environment and can be used for trainings and other temporary activities without affecting development in any way.
I think this training environment is similar to what Brent Swigert called 'sandbox environment'.
Please note, our Training environment cannot be used for SW evaluation and upgrades because this is just another instance of our dev server (where we of course don't install a new BP version while we still work with an older version).

We have another server VM for SW evaluation and upgrade preparation. It is located in our dev network. This application server shares the same repository DB with our dev application server. Probably it would be better to have a separate DB server for this evaluation server too.

For our last BP upgrade we used the evaluation server to grant users access to the new BP version, with upgraded copies of the current dev DB.
Eventually we used the evaluation servers to gradually upgrade our BP instances to the new version and making the evaluation server our new primary server, while keeping the current BP instances, just in case we need a quick fallback.

------------------------------
Walter Koller
Solution Manager
Erste Digital / Erste Group Bank
Europe/Vienna
------------------------------