hutbrazerzkidai.blogg.se - Electron app icon generator

#ELECTRON APP ICON GENERATOR .EXE#
#ELECTRON APP ICON GENERATOR UPDATE#
#ELECTRON APP ICON GENERATOR FULL#

Nevertheless, even if you have to wait for each to run one after the other, it’s much easier to debug if (when) one fails (and it takes ~the same amount of time as one long thread would have in any case). Concurrent jobs are great (although more than 1 concurrent build on Travis += $$$ ). Ready for another challenge, important feature we wanted is for each of these main processes to be created and run as separate jobs on Travis instead of one long process on a push to master. We’d like to eventually create an AMI on deploy and then spawn up instances from the AMI and add any spawned instances to the LB, which would then allow us to both decide on the # of servers at deploy and to scale up post-deploy in realtime, without first configing new servers then redeploying, etc. We reuse the build once -> deploy to multiple logic in Travis which makes deploying super efficient. We also have a separate ‘server-only’ meteor app that services many client requests (especially reqs to other external services, and another that runs lengthy cron jobs) to which a client (or method) connects over DDP (2 servers behind a LB), but this is a separate repo so it is a totally separate process. Slow: totalTime = servers.length * (buildTime + uploadTime).Fast: totalTime = buildTime + (servers.length * uploadTime), vs.

The implications are fantastic - scaling and deploying to multiple servers is now only limited by the actual upload-bundle-to-server time, and not also limited by the build time

#ELECTRON APP ICON GENERATOR FULL#

Without wasting build time of course, which was a challenge: when PM2 is configured to deploy to multiple servers, it builds & deploys for each server listed, which means you are waiting for a full build for each server! successfully configured the process to build once and reuse the same bundle to deploy to multiple servers.

Web: B&D the web app to 2 servers behind a load balancer.

And deploy it to the Mac App store (Appstoreconnect).

Mac: B&D a macOS Electron app (using meteor-desktop):.

#ELECTRON APP ICON GENERATOR UPDATE#

This way, we never have to update download links (it always points to the same spot which always has the latest version)

#ELECTRON APP ICON GENERATOR .EXE#

exe to the same location the old version was.

We save the previous version to a versions folder and write the new.

is still going strong and I’m confident he’ll get this one too !.

Windows: B&D a Windows Electron app (using meteor-desktop):.

And auto publish to alpha or beta testing channels.

Android: B&D an Android app to Google Play.

And automatically push the new build out to internal testflight users.

iOS: B&D an iOS app to App Store (Appstoreconnect).

Our project goals were for Travis to perform the following actions on a push to master (*B&D = build and deploy): Happy to say that Travis is successfully building a macOS app with meteor-desktop and uploading it to Appstoreconnect! Hey it took a while, a lot of luck, and more importantly, a lot of persistence from my relentless teammate (who gets 100% of the credit and is the expert on the matter).