Development and Production Environment Best Practices

[Gord Bond]

Hey All,

I was curious to get the community's feedback on how you approach the separation of the development and production environments for your projects. Our project is still in a development stage but would like to set up a production environment relatively soon. Are there any best practices or suggestions how to approach this in the documentation I've missed?

Our current plan is to purchase a second license and mirror the two environments. Is this the best approach? The big question this raises is, if we want more than one person developing on the project do we have to purchase another license?

How do you guys approach transferring data between these environments?

Thanks,

Gord

[Gord Bond]

A quick follow up question:

Would a MangoGT make most sense as a dev environment?

[MattFox]

I use a mango for local dev where I can. For the rest, duplicating your set up in the cloud is your next best bet.
If your changes are more aesthetics and UX rather than control then you can use NGINX with a proxy set up and a proxy based root directory to run a dev version of your dashboard elsewhere on the same server but leverage the same mango instance - not bad eh?

Fox

[cwangv]

@gord-bond
by using Mango hardware, you reduce the complexity of support compared to using your own pc. You don't have to worry about Windows or Mac numerous updates.

[Gord Bond]

Thanks @cwangv @MattFox I appreciate the feedback.

[Gord Bond]

@MattFox So if you are using a Mango for local development are you using any version control like github or bitbucket and pulling down from there for the production or are you personally using the cloud? I don't have any experience using Mango's cloud, so that is a bit of unfamiliar territory. If you have a moment I would really appreciate if you could further elaborate on your workflow.

[MattFox]

Yes I use bitbucket.
I use the gitflow approach so that all changes are pushed back into the dev branch then when all works, it gets pushed into the master.

I was developing when mango stored its mangoUI in individual files so when Jared changed to webpack it was a bit too late for me as my codebase is too big to rejig to work with the way infinite do things now.

Here's how I do it:

1. use a local mango and deploy your userModule and file structure in

[MANGO_HOME]/overrides/web/modules/mangoUI/web

mangoUI settings for userModule location are:

/modules/mangoUI/web/userModule.js

I like to throw a ?D=timestamp on the end to help if I've changed contents of the usermodule file.

I like the user module in the web directory then store all of my components etc in other directories beyond it.

2. Use git to commit all of my files that I need for the userModule and the userModule itself and push them into source control.

3. My mango cloud is actually a cloud based server that I host mango on, so I have full control of the system. This also means unfortunately if something goes to buggery it's my boss ringing me at some ungodly hour to fix it...

4. Where the main mango is hosted I pull the changes I have made and that updates all corresponding files.

5. To fight caching, when "requiring" certain files, create a version number constant at the top of the usermodule file. It's globally accessible and appends a dateTime string to it. So when files are called by mango you add on the end:

//Don't quote me on the DateTime format I'm on holiday!
const UM_VER = "?umVer=1.0.1_"+new Date().format("yyyyMMDDhhmm").toString();
//?umVer=1.0.1_202127010810

//which makes

define('./controllers/myNewCtrl.js'+UM_VER , function(newCtrl)
{

});

//or as an injected scope variable
['$scope', './service/myNewSvc.js'+UM_VER , function($scope,newSvc){
$scope.doThis = newSvc;
}
//other controller properties...
)

Hope that helps your build. I'll answer any other questions you may have later.

If you can implement nodeJS and use the webpack system Jared has implemented however, I'd recommend it as it gives you power over other users to amend any oversights or bugs in the main dashboard code and you can then build the dashboard files in the overrides directory with your own components as well. Saves you worrying about browser as much.

Fox