• Recent
    • Tags
    • Popular
    • Register
    • Login

    Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

    Radix IoT Website Mango 3 Documentation Website Mango 4 Documentation Website Mango 5 Documentation Website

    Development and Production Environment Best Practices

    Development general discussion
    3
    7
    1.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      Gord Bond
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • G
        Gord Bond
        last edited by

        A quick follow up question:

        Would a MangoGT make most sense as a dev environment?

        cwangvC 1 Reply Last reply Reply Quote 0
        • MattFoxM
          MattFox
          last edited by

          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

          Do not follow where the path may lead; go instead where there is no path.
          And leave a trail - Muriel Strode

          1 Reply Last reply Reply Quote 0
          • cwangvC
            cwangv @Gord Bond
            last edited by 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.

            1 Reply Last reply Reply Quote 0
            • G
              Gord Bond
              last edited by

              Thanks @cwangv @MattFox I appreciate the feedback.

              1 Reply Last reply Reply Quote 0
              • G
                Gord Bond
                last edited by

                @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.

                1 Reply Last reply Reply Quote 0
                • MattFoxM
                  MattFox
                  last edited by 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.

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

                  2. 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...

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

                  4. 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

                  Do not follow where the path may lead; go instead where there is no path.
                  And leave a trail - Muriel Strode

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post