iPS 276: Automating Painful Things with David House

In this episode of The iPhreaks Show the panel interviews David House about Continous Integration and Continuous Delivery. David is an iOS developer currently living in Georgia. He has been working in iOS development since the iOS SDK was int beta.  Right now he is working for a health care company, Kaiser Permanente.   David starts by sharing how he became interested in this topic. Kaiser Permanente is a large enterprise and has large enterprise applications. Their iOS app has almost a million users along with employees who use the app as well. This led him to find a way to scale an app for a large app while also maintain quality and security.    The panel asks David to breakdown the terms Continuous Integration and Continuous Delivery. David explains that neither of these terms was meant for mobile so they now have a different meaning. Originally, Continuous Integration meant you were integrating developer changes in an automated fashion. Continuous Delivery meant you were shipping out code in an automated fashion. Now CI/CD just means you can automate things and run them continuous through your workflow, not just integration and delivery.    The panel wonders how automated systems have effected that end of the workday ritual of checking your daily build. David explains how automated pull request has made this ritual obsolete. He explains the shift left approach which is the idea is to shorten the time frame between submitting your build and receiving feedback. With the rise of the pull request, this timeframe has been significantly reduced, essentially giving you continuous feedback. Pull requests can be a pain at first but David explains how getting into a habit of using them can say developers a lot of pain and worry.    David shares a life hack that also translates well to programming. The more you regulate the boring and the tedious the more room in your brain you have for interesting and new ideas. He equates this to automation. By automating the parts of your job that are tedious and painful, you free up time and brain space for the more interesting parts of your job. He uses the example of the pain and time it took to get an app into the app store, after automating that he had more time to do the cool parts of his job that he enjoys. The panel discusses how this can benefit the solo developer and not just a developer that is part of a team.   The panel considers how automation affects the way developers learn, does help developers avoid learning to do something for themselves. Unfortunately, David believes that true. He recommends learning how to do the things your automated systems do, it may just save your butt when your system fails. He advises thinking of automated systems as a minion. It is there to do the tedious and painful jobs you don’t want to do yourself but you should still know what your minion is doing.    The panel considers the various CI tools. David has used many different tools including Jenkins, Travis, CircleCI, Bitrise and the beta for Github actions. He explains that Bitrise is a great option, it is very visual and good for beginners. Github action will be good once it is released, the best part will be the community. Both Github action and Bitrise are opensource. Jenkins has been around forever, therefore, it has good roots and is powerful. However, Jenkins is not for everyone. David explains that there should be more tools to fill the spectrum of needs.    The panel considers security in automated systems. David explains that it is hard to tell which automated systems are more secure. They consider ways to determine how secure an automated system is. Open source is one way, you can look for holes in the system by checking out the source code. Also, some systems have a reputation for security.    The panel considers the lack of educational resources and good documentation for CIs. David shares how frustrating it can be to try and find a fix for a failed build in a CI. He...