Detecting the environment through a set flag rather than domain

Communities ColdBox HMVC
#1

Hi everyone,

I was wondering if there’s a way in CB3 that I can change the default environment detection from domain over to a simple flag we can set it the configuration.

Bit of background info on the reason I’m asking…

Our production environment is setup to email our student. Otherwise in Development we want to stop that and email the Development Team member who’s testing the app.

That worked all fine until one team member started to access their Development box externally through its IP address rather than the localhost domain. ColdBox wasn’t recognising them so it reverted to the default “production”. You can probably guess when the phone started ringing what happened with the email :slight_smile:

Anyway what I’d like to setup in the configuration is a flag. The default of which will be labelled as “Development”.

We use ANT for deployment so I want to get it to replace that token with whatever environment we choose on deployment. So deploying to production will replace “Development” with “Production”.

That way I’m not completely reliant on the domain name, which doesn’t seem to be 100% reliable :slight_smile:

Cheers,
James

That in turn would load in the correct configuration.

#2

This is a start, and you can use the standard config for email setting to modify for each develop so that the email goes to the developer instead.

http://www.andyscott.id.au/2011/4/15/Setting-up-your-ColdBox-30-application-for-development-and-production

Regards,

Andrew Scott

http://www.andyscott.id.au/

#3

And just after I post this I come up with an idea. Typical!!

Use the regular expression of . in the appropriate environment and clear the rest. So development would be …

environments = {
development = “.”,
test = “”,
production = “”
};

Test would be:-

environments = {
development = “”,
test = “.”,
production = “”
};

Phew!! :slight_smile:

#4

Thanks Andrew,

It was more the case that if ColdBox doesn’t match a domain it automatically loads in production, rather than me trying to understanding how it works.

In certain situations - like Development or Test that default could be “dangerous”.

i.e - if we have Contractors logging in and accessing their VMs over dynamic IP then we need to make sure we’ve coded all of that range into the configuration before they start accessing the application. Likewise if those ranges are ever changed by our System Team we’d have to change all the configuration files before anyone can use them again.

The end of not doing that would be Students getting emails that we’ve taken payment from them :slight_smile:

See the solution below but what I think I’ll do is get ANT to change the ColdBox configuration for each environment on deployment. That way I can 100% guarantee that no matter who accesses those files they’re going to setup the correct environment - nothing is domain name specific :slight_smile:

#5

Yes but if you use the detectEnvbrionment() this is not an issue, you use the actual machine name. If you get a developer who has not set this up, then you can default it to a senior developer or something. The point is that if you detect the production machine name, and you are not running in production NO email will be sent to the email address, provided that you read this setting to get the email address.

This is the most safe and effective way with little effort.

Regards,

Andrew Scott

http://www.andyscott.id.au/

#6

You also need to remove the IP address out of the equation and the domain name as well, look into what I said and you will see what I mean.

Regards,

Andrew Scott

http://www.andyscott.id.au/

#7

Great thanks for your time Andrew :slight_smile:

So if i put in what you’ve got blogged about then my environment is changed to the name “WEBTEAM06”

I guess I could code the detectenvironment to pick up the name without the number and call a function of WEBTEAM. Then each member can customise for their environments within there using the machinename.

Same would go for the other environments … they’re the same pattern with machine names and number.

Cool - I’ll have a think about that approach. You’re right that it would definately simplify things :slight_smile:

Thanks again.
James

#8

Ok … play devils adovacate here :slight_smile:

So we’ve got two production machines … called them PROD01 and PROD02

We use the machine name as a way of detecting the environment. So there we go we’ve got production boxes.

Along comes our System guys who bring in two new boxes, named PROD03 and PROD04 in prep for go-live.

They’re not quite ready but they give them over to our Development machine to test on.

ColdBox sees the pattern of PRODxx and bang Production environment kicks in.

#9

You may want to consider setting the environment based on machine name.

<cfset local.machine = createObject(‘java’,‘java.net.InetAddress’).getLocalHost().getHostName() />

#10

Which is what I pointed him to on my blog!!

Regards,

Andrew Scott

http://www.andyscott.id.au/

#11

I think you need to actually try it and see how it works for yourself, when you define something like I described in my blog post and I am sure you haven’t read it. It will grab the name of the machine, so if you have your machine named as you describe for your production machines, it WILL not revert to production if you have set this up for your development/testing/staging servers.

Like I stated if you do as my blog says, you end up with machine names that rarely change in any way shape or form. You can setup the application to always run in development mode, and if it detects the name it will run that function. Then in that function you set a flag to tell whether this is a production machine or a development/testing/staging environment, so for arguments sake let’s take your example a bit further.

string function detectEnvironment() {
return replace(createObject( ‘java’, ‘java.net.InetAddress’ ).getLocalHost().getHostName(),"-","",“all” );
}

Will get the name of the machine and return it to ColdBox, ColdBox will then check to see if you have defined that method, so you might have something like this.

void function prod01() {
modules.autoReload = false;
}

void function prod02() {
modules.autoReload = false;
}

void function prod03() {
modules.autoReload = false;
}

Then in the Global configuration you define it as being setup if it was a Development machine, and anything that needs to be different can be setup on a per machine name. Now the other thing that you could do is make it simpler for you is remove the numbers, so you only have one method for production, because the likely hood of it having different config options is very slim.

I think you might be getting confused with this way of doing it, but trust me when you understand how it works it is brilliant and simplistict at best.

Regards,

Andrew Scott

http://www.andyscott.id.au/

#12

HAHA, don’t worry I’m listening and trying your suggestions out Andrew :slight_smile:

Thanks Aaron… see my points above about how I don’t think it’s 100% bullet-proof.

Open to other suggestions by all means :slight_smile:

#13

Lol, no problem… But it is 100% full proof. I use it reliable for an application I am working on at the moment, and the only time it will fail is if the name of the machine will fail, and if it does it falls back to a development environment.

Regards,

Andrew Scott

http://www.andyscott.id.au/