> For example "everyone can deploy from master at anytime" is a great rule for a website that can actually be deployed by one click of a button, but a very bad practice for an iOS app, each new version of which can, theoretically, spend up to two weeks in review.
What is meant by that is that what ends up in master should always be working, complete, tested code, not half-finished stuff. It doesn't mean that you need to deploy each and every commit to the public. It means that master is the canonical source of truth for the current state, disregarding tasks that are not yet complete. It means that there's a solid base for people to branch from without worrying about things that are temporarily broken.
What I normally do with iOS teams is have the CI tool produce a new internal build for every commit to master. That way everybody, including testers, have the most up to date version of the application readily available. That starts to fall apart if developers treat master as just the place to put work-in-progress stuff. It doesn't mean that we're submitting to Apple several times a day, it just means that we're sure what's in master is "done done".
> What I normally do with iOS teams is have the CI tool produce a new internal build for every commit to master. That way everybody, including testers, have the most up to date version of the application readily available. That starts to fall apart if developers treat master as just the place to put work-in-progress stuff. It doesn't mean that we're submitting to Apple several times a day, it just means that we're sure what's in master is "done done".
I did that, but it turned out of little relevance to our QA process: new builds were happening once an hour, while QA wanted to get a version that they can run at least a full regression on, and it takes much more than that. So they ended up not using this CI builds at all, instead relying on a "release" branch version which they would get once every few days.
What is meant by that is that what ends up in master should always be working, complete, tested code, not half-finished stuff. It doesn't mean that you need to deploy each and every commit to the public. It means that master is the canonical source of truth for the current state, disregarding tasks that are not yet complete. It means that there's a solid base for people to branch from without worrying about things that are temporarily broken.
What I normally do with iOS teams is have the CI tool produce a new internal build for every commit to master. That way everybody, including testers, have the most up to date version of the application readily available. That starts to fall apart if developers treat master as just the place to put work-in-progress stuff. It doesn't mean that we're submitting to Apple several times a day, it just means that we're sure what's in master is "done done".