Setup for dummies
Closed this issue · 5 comments
I know how to use flutter but the signing and release process is complex.
Thanks for making fledge btw.
Can you make a doc.md to show all the steps.
Getting apple and Android stuff setup. Have to go to their web site and press all these buttons. Swords names etc.
Getting fastlane setup locally.
Travis can only do android builds. Can it do iOS.
Thanks for the kind words.
Yeah, it's something of a nightmare for mobile developers to deal with app delivery (double that for hybrid developers), and there is no single place that addresses it properly.
In an attempt to address this I started the Fledge project (to avoid the same fate for Flutter developers).
The Fledge project exists to first document the steps needed to deliver a Flutter app to both stores. It then progressively automates these steps (and removes from documentation).
Quite a lot of (good quality?) documentation has been created in the form of a guide/manual:
https://mmcc007.github.io/fledge/
Hours and hours, even days, of frustration can be avoided by following the documentation provided by the Fledge project (contributions are welcome where there may be places to improve documentation).
And so far quite a lot has been automated.
Some of the highlights:
- Complete automation and simultaneous delivery to both stores (not bad!)
- Default workflows for beta releases and user releases .
One simple command to start a workflow!
Couldn't be any simpler to use.
Automation is a huge timesaver. You probably at first won't believe how easy it is to deliver an app after automation has been set-up.
To address some of your specific points:
- yes, signing and release process is complex.
I recommend following the Fledge manual. - setting up in the Apple and Google stores is complex.
Use the Fledge manual here too. - Fledge has no local dependency on Fastlane.
You don't need to know Fastlane to use Fledge. - Fledge can use Travis (travis runs Linux and macOS) to automatically deliver to both stores .
(see this demo: https://github.com/mmcc007/fledge#demo).
Getting thru the (unavoidable) setup steps, although perhaps torture, is well worth it. You never have to do it again and you get the benefit of automation... what's not to like 😂!
Give Fledge a try and let me know how you get along. Your feedback is welcome, as it helps improve Fledge for everyone!
@gedw99 I think I know what you mean. Even with the fledge manual I spent most of an afternoon to figure it all out. I suggest you read the entire document first, and then start again and try to implement it. Sometimes you are stuck with questions that are answered in the next parts.
While I feel there is room for improvement there, I think it is best to do that later on, when the workflow has more or less settled. From what I read, @mmcc007 is still working and improving it. Let's do that first, before thinking about the best way to present te manual and having to change it again and again. (I would be happy to contribute to the documentation in a month or so, when I have some more time.)
I'm glad to say the Fledge (automated) happy path is working consistently and reliably.
On the happy path, Fledge will deliver any Flutter app to beta testers and then deliver a release to both stores, automatically and repeatedly, including for app upgrades. Fledge does this with two commands from the command line, 'beta' and 'release'.
The Fledge project comes with a manual covering the steps involved in setting-up a Flutter app for delivery. The steps in the manual are often automated in Fledge. When steps get automated, they get removed from the manual. This has already reduced the size of the manual significantly... and there are more reductions to come.
As more Flutter devs use Fledge, more feedback is generated, more features get implemented, bugs get fixed, and the manual gets smaller.
Feedback is welcome (and important) as it helps identify areas to focus-on for development.
I recommend you use Fledge to deliver your Flutter apps... everyone benefits from the feedback.
BTW: to contribute to the manual, fork the project and make updates to the gh-pages branch. Then create a PR. The manual is a collection of markdown docs (like the README.md).
Hey all, thanks for all the help !!
Will be digging into those gh-pages.