Continuous Integration (CI) originated as part of extreme programming (XP). Originally web applications where integrated once a week or once a month and every time a new version was integrated it resulted in an Integration Hell. Features broke and functionality was lost. To circumvent this integrations were moved from a weekly or monthly schedule to a daily or hourly schedule.
Before seeing the benefits of CI we first have to recap the broken workflow and I will try my best to map it to the iOS world.
Imagine you are a developer of a 3 person team at some large corporation in the 90s developing kick-ass iOS enterprise apps. You are spending your day developing a mind blowing visualisation of business data (really cool with pie charts and everything). Your colleagues are working on the data layer and integration with the backend. There are no stand ups, sprint planning etc. (I mean, you are paid to code, why spent all day in some rubbish meetings?).
You also have a deadline which is approaching quickly but you are confident as your code runs very smooth. As soon as your deadline is reached you will merge your changes with your colleagues.
Holy cow. What did happen? Your stupid colleagues changed the whole data layer that totally broke all your visualisations. Now your boss is getting angry at you and wants you guys to fix it as soon as possible. Even after you fixed all your merge conflicts in your Xcode project you are still faced with some significant changes in the data layer. You will spend the whole day fixing all your problems and go home at 5 a.m. with more bugs in your software than you might imagine.
While a drastic example and an unrealistic one (iOS didn’t exist in the 90s) it shows how broken things were in this team.
Imagine you are a developer of a 10 person team at some large corporation in 2015, developing a kick-ass iOS recipe app (your mom loves it). You are Head of Image caching in your team and you have an upcoming release. You are calm.
You pushed all your changes multiple times daily, so were your colleagues, the server ran all unit and integration tests and your beta is online and tested by your QA. You get a coffee and head home early so you can enjoy the weather.
What we have seen are two extreme scenarios which show the big gap between Integration Hell and Developers Heaven.
Continuous Integration describes a workflow which is proven to lead to a less stressful working life. Instead of integrating in large intervals, you integrate multiple times daily. You might also wonder what integrating even means, because you are so used to it you never thought of a word for it.
Integration means merging your code with the code of the others. Doing this in small intervals means you can react on changes and adopt to them in the code base more frequently. Integration usually happens in your Source Code Management (SCM) system, e.g. Git. It can happen when merging a Pull Request or merging a branch. All Integrations are stored on a central server, e.g. GitHub, Bitbucket or Gitlab and on your local machine.
A Build Server continuously reacts on new changes to the code base. After it is triggered it:
Because it is doing it so frequently you see failures immediately and are able to react to them.
Some popular CI services that support iOS and Mac devlelopment are:
I encourage you to try some of these out and find the one that best suits your needs and budget.
If you found yourself in the broken workflow story, I highly recommend setting up a continuous integration service in your company, most start with an old computer of a coworker. Start testing your code or just build the codebase to spot some configuration errors and you will soon be in Developers Heaven.
]]>I will focus on building Git2Go and the open source software around it. While the AppStore tries to be a hostile place for independent developers, I hope there will be room for productivity software that shifts iOS devices from being media consuming monsters to working machines on the go.
Hello World!
The current market for productivity software mainly consists of to-do list apps, with some exceptions [1]. We also saw some nice additions from Apple with the iOS SDK in iOS 8 and 9 with file provider extensions, split screen multitasking and additions to the built in keyboard. But software will not be the end. We are currently seeing rumors of an iPad Pro all over the Internet and the OS itself.
More importantly I want to experience my freedom of being self-employed and being able to travel through Germany seeing some friends and family. All in all, I think it will be an exciting journey and I am happy to hear your feedback!
[1]:
One problem developers in the pre-DevOps age where fighting with were the different environments your application runs in. Environments were not the same and bugs only occurred in QA or Live environments.
Possible environments are:
Development, your daily working environment. Your project local machine and the machines of your colleagues.
Test is the environment your quality assurance people run your applications that might be sandbox systems of your web application, your unit test configuration or even your Beta deployment.
Production is the live environment that is the AppStore for most people. But could also be an internal AppStore or the distribution system your enterprise app is distributed through.
The goal of streamlining your configurations is to get each stage of development as close as possible to each other. This makes sure you can reproduce bugs and your app is the same in all stages of development. The only parts that should differ are the ones specific to the environment, such as URLs, authentication keys and other constants. The rule of thumb is: The less, the better.
Things that should not differ:
Files that are compiled
Assets (images and text resources)
Code Paths
When I started with iOS development under Xcode 3 it was common to use different targets for each stage of development. You would have a debug target, a beta target and a release target and if you work on a legacy project you might still see this. Here is my tip: Delete them all.
Targets make everything very hard. When adding a class or an asset you have to make sure each of the targets is checked (which it isn’t by default). So it might occur that, when you compile in a different target, some classes and images are missing and you have no clue what happened.
The solution is to replace targets with configurations. You can add new configurations to your project in the projects settings in Xcode. Some valid configurations are
Debug to develop your app and run unit and integration tests.
Beta for beta distribution over HockeyApp or Fabric. You won’t need that for Apples Testflight.
Release for submission to the AppStore and Tesflight.
Of course there are some valid usages for targets and there is also a simple rule for that: Every extension has to be a target. That is Watch extensions, share extensions and today view extensions. For each of these cases Xcode is taking care of adding the targets.
If you have to differentiate between the different configurations do yourself a favor and use as little Preprocessor macros as possible. There are a few reasons against them
Complex macros don’t work well with Swift
they are not unit testable and
code enclosed is only compiled if the macro is active
At @xing we use different bundle identifiers for each stage. This also allows you to install multiple versions of the app at once. To see which stage we are running in at runtime, we use a simple method that gives back the current configuration. We only use these switches for different tracking suites and for the HockeyApp identifiers.
In your projects build settings add a User-Defined Setting and name it BUNDLE_ID_SUFFIX. Take the configurations as the value .$(CONFIGURATION).
In your projects Info.plist edit the CFBundleIdentifier value to com.YourCompany.AppName$(BUNDLE_ID_SUFFIX) this results in a Bundle Identifier like com.YourCompany.AppName.Debug.
You can add a helper method for getting the current configuration:
This approach gives you the opportunity to test your code paths in unit tests by mocking the infoDictionary.
If you are in need for different API endpoints for each stage, it is best to make them choosable from within the app.
Use a small UITableView to list them and let your beta users choose the environment they want to test in. This makes sure you don’t depend on a configuration, everything is exchangeable and it also leads to cleaner code as the options are clearly identified and documented.
I hope you do most of the things listed above already and if you take over a project or start a new one it is best to grab a pen and paper and get a clear overview of the needed configurations. Simply write them down and identify the differences. Make parameters exchangeable and use Xcode configurations over targets.
]]>The Phoenix project is a fictional novel about an IT manager in a car parts manufacturer called „Parts Unlimited“. This company is organized in the most old fashioned way you can imagine. In the beginning of the book the protagonist gets promoted and faces the mess his predecessors left, naming a desolate IT infrastructure with systems failing every hour and more outages than you can count. Shortly after his promotion he begins his renovation journey supported by an experienced mentor who used to manage production lines. Long story short: he slowly comes across the DevOps mindset and introduces it in his company. Systems are getting more stable, developers spend their time on developing features not mitigating outages and people are getting happier. I don’t want to spoil all of it and if you are interested I highly encourage you to read it.
DevOps is coming from a time where you developed an application and had 3 months plus release cycles. You would hand your carefully crafted software with incomplete setup instructions to the operations team to deploy your project. But every second time the deployment would fail because your development, test and production environment wouldn’t match. The final integration was never tested before. Deployments are a series of manual tasks you would run on your root server in order to provision it. Once in a while you forgot one and the application failed to run on the server correctly.
After seeing that for some decades some smart people came around and thought they could do better. They build cross functional teams namely: Developers, Operations, QA and product managers. But, they did not only bring everyone together, they also worked on automation. They streamlined creation of development, test and production systems and checked everything into version control. What has been a manual setup process for new employees taking days to get setup, now is a simple script. The same way you configured your computer, you would provision the server to match the packages, scripts and code. Tools like Chef, ansible and Capistrano where developed to help you even further.
Teams would take over responsibility for server provisioning and deployment and go from 2 - 4 releases a year to 10 deployments a day. This reduced the feedback loop, features could be developed much faster and overall developer happiness increased.
While working at my previous companies I have seen a lot of things go wrong and a lot of things go right. When reading my Twitter stream or talking to friends I hear things like:
„Sorry, I can’t join for beer tonight. I have to release a new version“ (Friday evening at 10 pm)
„Code signing sucks, Apple should fix that.“
„We build because our release configuration is different from our Beta config. Some files and images are missing. It sure worked on my old computer.“
Once you realize that you have the same problems as an iOS developer in 2015 like the backend folks had 5 years ago, you begin to think that we are not that different. The one and only solution of this is to adapt your work to an DevOps like workflow: Build cross functional teams, streamline configurations and automate.
In the following weeks I will write blog posts about:
I saw some great impact at @xing, once we increased the automation in our team, even when we where only 2 - 3 people. We now do biweekly (App Store) release cycles and everything just became easier since we have automated the tasks we do over and over. For us building an App Store release is nothing more than pushing to a branch and each step is automated afterwards:
All the automated testing and manual quality assurance of features took place continuously during development.
I would even go so far to say that even if you are a sole developer working on your part time project, automation can save you hours, if not days, of work. It also reduces your stress level when you know that doing an App Store release is nothing more than a commit (yes, even code signing).
]]>There were this very cool looking BMW Z3, Z8 and the famous 750iL which he drove through Hamburg (the city I am currently living in). Every vehicle he drove was equipped with all kind of cool things from missiles over spikes to fax machines. The coolest thing for me was the Ericsson JB988 he used to steer his BMW 750iL in „Tomorrow never dies“. Although just a concept phone I fell in love with the idea to have such a powerful and diverse technology in my pocket.
Later Nokia started producing the communicator line in 1996 starting with the Nokia 9000 Communicator. Although I can’t remember the first model I still remember the Nokia 9210. It came out in 2001 and featured a 66 MHz processor, a color display and a real file explorer. Of course it was aimed at managers and other busy people, but as a kid I wanted it so badly because of the first Bond movies and the endless things you could do with it. I asked my mom if I could get one of these and she had a friend who got one. She asked her about the device and she really didn’t like it. It was very heavy (244g), had an internal hard drive and because of that it had no vibration alarm on it. Mobile internet access was still a pain, very expensive and so my dream went unfulfilled.
I have had a lot of mobile phones since then starting with some regular Nokia devices like the 3210, 3310. Despite the usual suspects I always were a fan of unusual phones. I started my career as an owner of non-regular phones with a Nokia 5510. It featured a full qwerty keyboard but besides that it was a usual phone. But it looked very cool and different. I also owned a Nokia N-Gage which was meant for playing games you could purchase in a physical form. But despite them getting better displays and increased processing power I was still far from my James Bond experience.
And although I could talk about the mobile phones of my youth for hours and hours, it is time to move to the mobile phone that changed my live in a very significant way.
The path to my first iPhone is a lengthy story. As you all know it came out in 2007 and I was 16 at the time. Purchasing an early iPhone while living in Germany wasn’t the easiest thing at this time. You had to wait until November 2007 to buy an official one in Germany. But of course you could not just buy one, you had to agree to an overpriced contract with T-Mobile or GTFO. My parents aren’t very rich and getting a 50€+ per month contract to your 16 year old son is not the wisest thing you could do. So we searched for alternatives and found a way to get two contracts (one for me and one for my mother) and get an imported iPhone with it. Of course the deal failed because the dealer went out of stock. So he gave us 700€ and we bought an imported one for 586€ on eBay.
I had to start working because I paid for the phone and the contract myself. So I started working in a Pizzeria nearby cleaning dishes for 25€ a day. Still I was one of the happiest people on earth having a first generation iPhone in Germany. It was very rare and everyone who had one was pretty proud of it. I remember getting it delivered after lunch but the battery had died so I couldn’t try it out immediately. After my shift at the pizzeria (which was about 7 hours) I finally went home to get to know my new friend.
I immediately jail broke it, because that was what you did at the time, to install some apps. I stayed up all night until my mother got up at 7 in the morning showing her all the stuff I found out in the night and went to sleep.
After installing some early apps like the piano keyboard (which name I don’t remember anymore), some cool ringtones and downloading some songs, I realized that I couldn’t just start our car and drive with it :wink:.
While doing my apprenticeship I got my first iPad which was an iPad 2. I decided that I didn’t need the first iPad because no apps were really ready for it.
I used it once in a while but not really much. Owning one was more a status than a need. I also think I wasn’t using it much because I would use my MacBook and do some programming instead, which is kind of silly. I believe that to craft beautiful iPhone and iPad apps it is a necessity to own and use one excessively. That is why I introduced iPad only weekends when traveling to various relatives. These weekends made me realize that the iPad ecosystem is far, far from perfect. I don’t think this is because of the device itself. It is mainly because the apps really don’t play together. Let me give you an example:
Me and my girlfriend were visiting her parents and went on a boat trip on a small river. Immediately I took the opportunity to use my GoPro, which is laying in the corner 364 days a year and I took some amazing underwater videos. I imported them to iMovie the same day using the Apple Camera Kit and edited them in iMovie. Editing in iMovie on the iPad may not satisfy truly passionate filmmakers but I found it very joyful. Of course to increase my social media footprint I wanted to upload it to my almost empty tumblr account. That’s where things hit the fan and I discovered that uploading a 50 MB video from the iPad is the worst thing you could try. I used the tumblr share extension and it failed silently or just aborted at some point. I was so disappointed that no one saw the video ever again.
That may be an edge case for most people, but I was so encouraged coming that far with just a GoPro and an iPad that all my excitement went into sadness.
If that example was too special for you that’s totally ok, but let me give you another short one:
I would love to blog more and being a programmer I would love using jekyll for that. Guess what: there is no easy way to blog with jekyll on the iPad. Of course there are a ton of markdown editors out there and they all are perfect for just that, but how do you get that piece of art on your blog? Here is the solution: You need a laptop, git and an email address (or iCloud). If you are done writing you just sent it to yourself, open the laptop and do the usual commit and push on the laptop. I find that far from optimal.
Not only the broken workflows are a problem but also the cross device experience. A while ago I went back from using AirMail, Chromes and others to using Apple apps like Mail, Maps, Messages, Safari. I don’t think you can get that kind of cross device feature rich experience from any third party business, yet.
I write this article on my 3rd gen petition iPad mini on Ulysses which I find nailed the writing experience on the iPad and on the Mac. Everything just works the same way (except for the statistics) and I don’t have to think if I am on an iPad or on the Mac.
After you heard me complaining about all the issues I have, let me give a short conclusion:
What does this leave us with? I have to create some apps, brb.
I decided that in order to solve my own issues and potentially the issues of a few more people, I need to tackle them myself. That’s why I want to pursue my dream of nerdish by nature becoming a small company crafting beautiful universal apps for professionals. I think we as professionals are left out most of the time and a lot of developers only think about photo editing and sharing apps because that’s where the money is. Don’t get me wrong I find photo apps cool, too. I just don’t take photos, I create apps.
Maybe doing apps for professional usage is a bold idea but I am happy to try it.
]]>