I like the idea where you can manage 2 streets with lifetime, but the above situation is bit strange (the second street should be in another licence). Think it's a work around to prevent another licence so you'll have chosen (by cost reason?) for this solution and you'll should also accept the workaround you'll have to apply.

Guys,

What I used to see in some cases is that different streets are related to different business lines like internal applications (B2E) and external applications (B2C, B2B).

Is this your case? Please share your reality.

Thanks

Yes and no.

For us it was more the legal separation (so to separate risks) for some of the applications in another street.

Kind regards,
Evert

"Guys,

What I used to see in some cases is that different streets are related to different business lines like internal applications (B2E) and external applications (B2C, B2B).

Is this your case? Please share your reality."

Hello João and Evert

I want to Share my reality:

We have 9 environments divided by 3 streets.

1st Street: Citizen Development (3 Environments , DEV, TST and PRD - On Premises)

2nd Street: Business Applications (3 Environments , DEV, TST and PRD - On Premises)

3rd Street: Customer Facing (3 environments, DEV, TEST, PRD - Cloud PaaS)

Different teams work in these streets, but sometimes we can move some application from one street to another (CIT to BA).

For now, we have two lifetimes (one in Cloud and other in On Premises to manage 6 environments) but in future could be only one Lifetime to manage all environments.

But is difficult to manage all environments in one Lifetime:

First: I have to minimize to 60% to see all environments and horizontal scroll bar doesn't fix the panel of applications (I will add other idea with this improvement) 

And the most annoying warning is:

This is not a hotfix because is a DEV Environment from a different Street.

My idea is to create a  Street (father) to add environments (child) inside.

And only the admin could see all streets.

I hope this could help.

I think this is a very cool idea, especially for very large factories!

Hello Luis,

Are you aware that you'll can also do something with permissions for a user?

For example: you'll could create a role (developer Citizen) which only has permissions to those DEV, TST and PRD environments (set other environments on NoAccess and then they will only see the Citizen development street.

Think you're usecase should be that DEV-TST are the same environment for each street and you'll have different production environments. With roles you'll can configure who is working in which street.

Kind regards,

Evert

Great Idea!

Hi Diana Milheiro,

Thanks for the feedback.

Evert van der Zalm we managed like that but we have a lot of limitations...

• Architecture Dashboard only works for one Development Server;
• Still have the hotfix errors on the second Development Environment;
• there was some bugs reported to Outsystems regarding roles (some users from second street without the right permissions)

Thanks,

Luís

Hello Luis,

Why haven't you chosen for one DEV environment? Even the TST environment could be the same, but can image that (load) test should be done separately. From there an application should be published trough the street. As written before (don't know about the permission bugs), you should be able to create teams where you'll have environment specific applications and global applications and people only see what they need (maybe operations and admins who see all, but they probably know what they are doing).

Think some issues will be solved when they are configured on another way.

Kind regards,
Evert

Hi Evert,

I prefer your solution too, with one DEV and then two TST and two PRD.

We have a hybrid solution with OnPremises (6 environments) and Cloud (6 environments), 

there are applications only  internal ( OnPremises - B2E and B2B apps)

and the customer facing development (Cloud B2C apps )

In these B2C applications we have different SMTP Servers (Service Center allow only one per environment), Reverse Proxy, VPN Connections and SEO Rules and they decided to split.

If we had only one DEV it was very difficult for developers test the emails, debugging the code, etc...

I hope this helps to understand...

That is quite a set-up you'll have there (-:

Have read everything above but there you'll mentioned 9 environments (6 on premise (so the screenshot with the issue?) and in your latest reply there are 12 environments, so this is correct?

Regarding the one DEV environment, this would be for the on premise part, the debugging shouldn't be an issue right? With the correct team set-up the developers only have rights to their applications so the teams can't interfere with each other when debugging right?

Regarding the e-mail that issue can be solved by a work around where, only on the dev environment off-course, you'll a 'tag' to the e-mail subject, send it to a redirect e-mail box and from there set-up rules to forward it to the correct e-mail. We've used something similair for one mailbox to seperate DEV e-mails from TST e-mails and to separate e-mail for separate teams. Not the best solution, but it works.

The harder part is indeed the B2C applications, but there the question would be if you'll really have to split the whole street? The Development and testing would be internal right (so also on premise) so can have the same configuration as the dev and/or test. When pushing to acceptation, then it goes to another server (cloud) for acceptance testing (this could also already be done with test if feeling needed) so all the other configurations (SMTP, reverse proxy, VPN, SEO rules can be tested on those environment(s) before going to production.

It's not the ideal set-up and this also means good responsible and agreements between the teams, but it should be possible right? The time you'll save by having a good overview in lifetime would really help doing everything quicker. Have made an overview on how you'll can set it up: