When I wrote this part of the series, I started it on a Mac. Along the way I had to write some of it on a different computer, running Linux. So I decided to change the contents a bit of this post. I will still get the App in a container, but I will show it to you for the Android platform as well as iOS. Part 2 will therefore be split in two (an Android part and and iOS part).
Everyone knows Facebook, the biggest social-networking site. It is one of the largest sites of the planet. For years they have run their site on a customized version of PHP, named Hack. Not so long ago they switched to an internal product for parts of their site. This product is called React, it is a JavaScript framework. It’s star rose quickly internally. The crux of the product is that it is a component-based, decoupled way of developing software, which is based on the best ideas from computer science about good design.
Last week I have done a presentation to explain to colleagues how they can use the CI and CD infrastructure I have put up for us. The image links to the presentation:
My blog has been running on the Wordpress platform for years. During the last year my development focus has been partly learning javascript and mobile development. As such, the time has come to put that knowledge to use in my personal projects. In the last couple of weeks I have migrated the old Wordpress platform to a new platform: Ghost It is pure javascript and is more focussed on pure publishing than Wordpress.
In the wonderful world of crossplatform App development it’s hard to do end-to-end testing and CI. We have been able to setup CI for the CHECK web application, and I wanted to use the experience to make it work for mobile as well. Those React mobile apps generally run in a Cordova container, not as a native app. Of course there is the React Native project, which will run directly through a javascript bridge, but for now we are still using Cordova.
So now you’re reading this trying to find out ‘who’s this guy with this weird blog!’. So that would be me then. Let me introduce myself. I’m married and have two kids. Started working in IT in the 90’s after a failed attempt to study Public Administration. I liked it so much, I stayed in the industry. Started as an administrator, got to developing and now I like both worlds.
Building a Continuous Delivery flow was not our only goal. Getting automated testing in there would be very helpful. So the first idea was to get visual testing going using Appium. That took me a day or so, but we got it working. The tests are very simple and for now only prove that tapping or clicking works, the assertions are not finished yet. Tests are written in ‘Mocha’ style and can be executed from the command line and as a job on our Jenkins servers later on :
So now we are a day forward in the new year and I realized I’d like to say something about it. For me 2015 has been a big year: finished my studies, learning new things about javascript, cloud business, apps, Agile and DEVOPS, amazing vacationing to Portugal with my love, a couple of weeks in the U.K. with the family in the summer, getting to run 10 KM … a lot of things.
This year we created Continuous Integration (CI) for CHECK, but since last month we also are in the process of creating an automated build for our mobile projects. In the DEVOPS and Agile world we call this Continuous Delivery (CD). Why would we do this? Mainly for trying to speed up delivery of applications and in shorter iterations. We noticed in the initial projects we lost a lot of time because of deployment issues, especially with all the different App Stores around.
We are using Jenkins Continuous Integration Server for automating tasks that would otherwise take days and generate more errors surely. We build the database server and web infrastructure daily for our most important application (legacy with asp classic,NET 2.0/3.5 parts and a lot of Oracle 11g PL/SQL components). When completed, a set of integration tests are run with selenium. Deployment workflow How we came to this While developing on a dedicated test server for years we encountered integration problems frequently when deploying code to production.