Keep the codebase in a repository or on a development server ideally, even when working alone, it’s a good practice that can save you a lot of troubles and time when either starting to colaborate with someone or when the product needs to be pushed to a server for deployment.

Hi @Kenneth Chen,

 

You have several ways of managing this, I can share with you how I would do it:

• Each developer should create a Miro developer account
• I would configure my project to use something like localtunnel that will allow you to always have the same URL exposed to the internet when starting your server. You can see an example in this boilerplate. You can set the subdomain of this URL as a configuration variable so each person working on the project can configure their own URL easily. 
• I would host the project on a source control management tool like GitHub/Bitbucket, keep the main repository with only the main (master) branch as a product working environment in which I will enable automatic deployment into a server (you can use many tools for this like Travis CI, Circle CI, GitHub Actions).
• I would ask each developer working on it to fork the main repository, create a feature branch in their fork and develop there. When they are done with their development (or even before if you want to review/discuss around the code) to open a Pull Request from Fork/feature branch → main branch on main repository.

 

Locally each developer will have a working environment using localtunnel and can test while coding in Miro using their personal developer account.

Every-time a PullRequest is merged into the main repository, the plugin will be deployed and ready to be tested on a specific environment (you can configure a specific developer app for this case with a pre-set URL). 

 

When you are running this in production with customers you need to add a phase (can be a branch on the main repository) to have a testing environment before going to production.

 

Hope it helps,

Anthony

@Kenneth Chen  

Glad to hear your bringing a team into action on Miro app dev! 

There’s already a lot of steps in team dev and deployment and indeed Miro app dev adds a few more … It took us a while to sort out how we go about this at Refractive … but I think we have it reasonably sorted at this point. 
 

Here’s some things the Refractive team learned building Clusterizer, Totally Random and other Miro apps for clients. Hope it helps! 

If you want to develop an app that is: 

1. Production quality with customer users
2. A public testing beta branch with tester users
3. Has multiple developers 
4. Has various feature branches

Here are some things to consider: 

 

First a glossary for clarity sake: ( I find language game alone can be challenging )

• app: lets use ‘app’ to mean each instance of a Miro plugin, each created separately in the Miro apps admin console, and each with a different ‘Client ID’.
• app Miro title:  This is the title you put into the Miro app admin console. This is only public facing to the user at the time that they install or auth your app. 
• app html title: The header title on the actual interface of your plugin. Most likely at the top. 
• app icon: this is the SVG icon specific to your app, it will show up on the toolbar where you specify. if you have 10 apps installed with the same app icon on all of them you will see 10 of the same icon. 
• app toolbar title: the title that show up in the miro toolbar when a user hovers cursor over your app icon. This is the ‘title’ specified in the ‘miro.initialize’ function of the plugin. 
• branch: a git branch of your app’s repository

Steps to multi-dev Miro App development

• Team version control / Github side
  • Do what @Anthony Roux describes, and what is in the Miro SDK documentation 
  • If you need more support in that area look at examples of git workflows: ex: Atlassian Git Flow
• Miro side: for each app … 
  • In the Miro app admin controls, create the following apps: Create the following Miro App Titles.
    • “ p your app title ] + “- Production “
    • “ > your app title ] + “- Beta “
    • “ œ your app title ] + “- Dev -- “ your personal name ]
      • This will be your personal working Miro endpoint of your development environment
  • Setup your team: have each developer on your team…  ( @Anthony Roux  lays it out well )
    • Create an acct under your Miro Dev team - or...
    • Create their own dev team ( either will work )
  • Have each developer create an app titled: 
    • “ < your app title ] + “- Dev -- “ d their personal name ]
    • This will be their personal working Miro endpoint of their development environment
  • Workflow:
    • Dev: When each person on the team develops they will develop, break, fix, and perfect their code, their features, to their ‘ppersonal name]’ app. 
    • Deploy: When the team deploys:
      • Pull Request and get your beta or production branch sorted out as it merges in the feature branch(es) using the version control tool / git. then... 
      • Serve that branch to / link the served URL to the associated Miro ‘app’: 
        • “ your app title ] + “- Production “
        • “ t your app title ] + “- Beta “
      • You’ll need your solution for serving your production / beta apps …   (cdn): 
        • github pages
        • netlify 
        • cloudflare
        • those that @Anthony Roux described
        • etc. 
      • Now you’ll have a nicely insulated apps that allow for all the experimentation you’ll need. 
    • NOTE: 
      • If you install all these apps you will have: 
        • 4+ app icons in your toolbar: prod, beta, yours, + 1 X number of team member apps in your miro toolbar. 
        • if those apps don’t have different icons, then you’ll suffer from knowing them apart. 
          • you can move the apps once you know which is which, putting whichever you’re not working on, back in your library tray, and the one you are working on over in the toolbar. 
        • What I do is make 3 things (other than the ‘app miro title’) unique for each Miro app: 
          • the app icon
          • app toolbar title
          • app html title

 

 

I got tired of making the code switches at every deployment so I have done the following in the codebase to make it a bit easier :

 

--- 
Cheers,

Max