Digital product workflow
In the broadest possible sense, digital product development pretty much always has the same rough workflow.
The code is written, an app is built, the app is deployed (sent out) and feedback is gained. That feedback then influences the next code to be written and the cycle continues.
To help a product be successful, it’s imperative that this process is completed as quickly as possible. The more versions, the more improvements, the more feedback, the better the product.
We can’t automate the writing of code. At least for the foreseeable future, it is still done by humans. But the process of building an app and deploying it to users can be automated.
Not only can it be automated, it should be too. It is so time-consuming that it makes a lot of sense to use tools wherever we can to make it quicker.
For example, below are a few of the things that we need to think about to create and deploy even the smallest changes to an iOS app:
- Code signing
- Provisioning profiles
- Cocoapod management
- Breaking changes from new Xcode versions
- Creating / updating screenshots for the App Store
- Push notification profiles
As you can imagine, we do a lot of iOS builds across many apps. Anything we can do to reduce these tasks is definitely worth doing. And that’s where automation steps in.
The automation processes are broadly split into two areas:
- Continuous Integration (CI) - this is where the code that has been written is tested, merged and made into a ‘deployable’ build. I.e. an app that can be installed onto a phone or tablet.
- Continuous Deployment (CD) - is the process of getting that build (app) out to devices so that it can be used/tested.
The CI process takes the code that we have written; builds it, tests it and then rejects or accepts that code depending on the testing outcome.
Automated tests are really important for our projects. Tests are written in code to test the code that has been written. It sounds a little funny at first.
But when an app has 1000’s of lines of code and multiple people have been working on it, you want to be confident that writing new code doesn’t break something. And the way to get that confidence is to have a bunch of tests that automatically run every time that you change anything.
For mobile apps distributing builds is particularly challenging. When developing websites it's straightforward to set up a staging environment and share a URL with whoever you want to test your site.
But, for apps, the normal way of sending out builds is through the app stores (e.g. Google PlayStore and iOS AppStore), and we can’t do that for builds that aren’t ready yet.We have to send those builds directly to devices for QA teams, clients or beta communities well before they hit the stores.
There are different ways of sending builds. Once we’ve found the methods we want to use we can automate that process so it’s repeated easily.
The ultimate benefit for utilising CI and CD tools is that we can channel our creative energy into creating and improving great products.
We have a team made up of many different specialists and we want each member to be able to bring their best to each project. That means we want all our developers to be confident to make changes knowing that they aren’t going to break another section of the app.
If to make any change each developer had to build, retest the whole app and then labouriously distribute it, it would slow us down immensely.
Good automation processes allow us to get through the feedback cycle quicker and create better, more stable, products.