I develop on a MBP. Can't imagine using this alongside regular XCode build/run cycles.— Igor Makarov (@igormaka) February 19, 2018
@qnoid Also interested on your thoughts as to processor overheads if developing and debugging whilst Windmill is running. Dev > commit > push > dev > commit > push ... is a common workflow for me. I wonder if Windmill might run at inconvenient times and slow this down?— Sammy C (@dubblewordscore) February 19, 2018
“I commit code quite frequently during the day.”
TL;DR Windmill monitors your master branch. You can utilise it every time you merge and push to master while you keep your existing development workflow on a feature branch.
The goal of Windmill is to establish a process that enables you to:
- know when your app can no longer be released, give you the reasons that hold you back and provide you with feedback/support on how to resolve them.
e.g. build no longer compiles, distribution certificate has expired etc.
- monitor the “quality” of your app through metrics and reports.
e.g. do tests pass? how many tests are there? what’s the code coverage?
- see the “progress” of your app by providing you with an IPA that you can install on a device
e.g. does the “pull to refresh” feature look and feel as expected?
This, among others1, is the value that Windmill aims to provide you with.
Windmill is not meant to be used while practicing TDD, working on a feature branch or as a replacement to a continuous integration service2.
Windmill exists to monitor your master branch for release candidates. A candidate that you decide when to turn into a public release by evaluating what is in front of you.