To achieve an efficient workflow for rapid iOS app development you have to specify the automation scenarios and the triggers to start specific scenarios.
Additionally you most likely want to minimize the number of tools, configurations and manual steps required to achieve your automated development workflow.
To make the whole process as easy as possible (and still flexible enough to support a broad range of tasks you might want to perform as part of your automation) was one of the fundamental principles when we started Bitrise.io.
Through hooks git is ideal to be the trigger of your automation scenarios, no other tools required.
Well, actually there’s one more thing: you have to organize your git repository branches in a way which is easy to manage and also which can be used to identify what automation scenario should be performed when a change happens on a specific branch.
Let’s do it! ⚓
The most popular git branching model which fulfills these requirements is Gitflow. You can use other branching models but we’ll use Gitflow jargon to describe the concepts.
A very minimalistic summary of how Gitflow works:
- You have two fixed, main branches:
- master : it should only contain the code of release versions
- develop : it’s the root branch for development, the integration or synchronization branch for developers
- You work on feature branches:
- Always start the feature branch from the develop branch.
- Once a feature (issue / task) is finished you close the related feature branch, merging the feature’s code back to the integration develop branch.
- Once you’re ready for a release, you merge from develop to master (through a Gitflow release)
With this model you can always see the active tasks (feature branches), the latest “staging” or “beta” code (develop branch) and the released versions (master branch).
Your branches have separate meanings / purposes, which make this branching model a naturally good fit for automation.
So with a branching model like Gitflow and through webhooks, you can define and automate three main scenarios:
- Change on a feature branch: while a feature is under active development you mostly want to continuously test the code, checking whether it still fulfills the defined tests, so when it’s finished and you merge it back to the develop branch, it won’t break anything.
- Change on develop branch: this is the main integration point of finished features / tasks. If you or your team works on multiple features simultaneously, those independent features might introduce conflicting changes, so you want to always test the code changes on develop to detect these breaking changes. If the tests do pass, you or your testers might want to give a manual spin for that particular version of the app, so you configure an automatic deployment which should make the version accessible for those use are in charge of testing the new versions. It’s also a good idea to notify the testers when a new test version is available.
- Everything worked, your app is rock solid, was tested both automatically with unit and other tests and manually by your internal testers, and now it’s ready for prime time. Fantastic! Now you can create a release, which in Gitflow will merge the code from develop into the master branch. As always, just to be absolutely sure, you want to run your automatic tests one last time. If it passes you want to build the release version of the App, deploy it for your external beta testers / your project manager / anyone who agreed to test your precious app before the App Store submission. And of course you don’t want to forget to invite your testers, do you?
The beauty of Gitflow (or a similar branching model) is that if you use an automation service like Bitrise you can define these scenarios, connect to the related branches and you’ll never have to do these tasks manually.
You can just work on your code, organized into branches and that’s all. Everything else will happen automatically, based on which branch changed.
Git + Bitrise ⚓
Bitrise is built specifically to help you with this kind of automation. To achieve an automated workflow like the one described in the previous section this is all what you have to do:
- Register your App’s repository on Bitrise (Don’t forget to setup a webhook! If you connect your repository through our GitHub or Bitbucket integration options, Bitrise will do this automatically for you).
- Prepare your App’s Primary Workflow to include the tests you would like to run on every code change.
- Create a new Workflow for your develop branch and add the deployment and notification steps you would like to use. For example, you can use Bitrise’s built in App Deployment system and send email and Slack notifications when a test build is available - you can find dozens of Steps in our library or you can just add script steps and do anything you want to.
- Create another Workflow for your master branch and configure it for the deployment of release versions, notifying your beta testers or project manager, maybe even Send a Text message.
That’s all, no other setup is required. You can customize your Workflows the way you want and you can control everything with nothing but your code repository!
We have a great amount of Steps you can choose from and all of these Steps are open source, so if you want to modify one or create a brand new Step you can do that too!