Why the last thing a developer should do is to commit to repo? The magic comes after.

Authors: Tomasz Soroka

Developing apps is a bit like piloting a plane, for You will know a good pilot by how he tries not to interrupt the auto-pilot ;)

Not getting into the discussion about the pros and contras of work automatisation I can easily state that it’s far better to assign all the repeatable tasks to a machine rather than a human being. As intelligent and efficient coders may be, it’s really crucial to eliminate all the useless and pointless activities from their schedule. At LEAWARE we believe in finding great solutions while minimalizing the unnecessary cost and the possibility of making a mistake.

Do You know why the last thing a developer should do is uploading code to the repository? It’s actually the last moment when the developer interferes with the process. From then on, everything is automatic… If You’d like to know more about how it goes with a cross-platform mobile app for iOS, Android and Windows 10, read on ;)

If You’d like to know more about how it goes with a cross-platform mobile app for iOS, Android and Windows 10, read on ;)

  1. The pure code We test all the typical mistakes in the code, such as misusing class, functions, Variable. We try to catch all the incoherences, or in other words - mistakes in grammar.
  2. Three compilations Then we compile the code - after each change introduced by each coder, we want to make sure that the compilation goes fine on each of the 3 platforms.
  3. Testing The next step within a proper compilation is proceeding with all the unit tests that were written for the app. We need to check how the app works in its particular parts. There may be even several hundred of these tests, but they let us see immediately if the changes we had made and new functionalities we introduced have not interfered with the code.
  4. Release If the testing goes well, the app is ready for release. We put the compiled versions of the app dedicated to each platform on our inner distribution server - this way all the users (and the clients as well) can easily download and test the app on their devices. Keep in mind that on this level we've got 3 versions of the app made for 3 platforms.
  5. Is the app user-friendly? Next stage is the User Interface test - this is when all the magic happens ;) First You download the app, which was compiled for a proper platform and install it on actual devices: smartphones, tablets, PC's, kept in our server room. The tests simulate user's activity, we don't need to test them manually. We can rest assured that all the written tests proceed properly and be sure that none of the elements suddenly stops functioning. If any negative results appear, we are reported immediately and we can improve the code precisely where it needs to be corrected.
    Plans configuration example on Continous Integration Server
I need to add one thing - the number of the stages of the development process may vary depending on the particular project. It's different with an app that You build from scratch and different with one that is just an update of a previous version. Making a final release - the version of the app that You can put in app stores - is still a couple of steps ahead. In my future blog posts, I'm planning to get deeper into these processes and explain the differences between them.
Tomasz Soroka

Summing up  - what are the advantages of the approach I have described above?

  • We save a lot of time needed to prepare a new version of the app - each new release dedicated to each platform takes about 15 minutes. That gives us a precious extra hour or even two in terms of developers' schedule!
  • We can avoid making any mistakes during the process of preparing the new version of the app. Thanks to all the stages of testing we are able to track down any failures much sooner.
  • All the mistakes made in compilation can be detected very fast. A change within fragments of the code’s core determines lack of compilation on all the 3 platforms.
  • We can detect any errors with uni tests - and by errors, I mean mistakes in logic that may cause some components of the app to stop working.
  • The particular versions of the app are numbered automatically - because of that we are able to check precisely how each version of the app works on each level of the process ( testing, staging, production).
  • The tests are performed automatically - the UX testing on each platform can take up to 4 hours on one single device. With 10 devices being tested automatically we can save even 40 hours of a human tester's work! Apart from that, we need to be certain that the tester doesn't make any mistakes.
  • The apps are immediately available for all the members of the team and for our clients. Each intervention in the code is being tracked down in terms of potential errors. If we manage to find any, we can quickly see where the problem lays and correct the code. We save our clients' time and due to our agile approach, we can provide them with high quality solutions.
As You can see, the methods we currently use in app development are based on segmentation of the process into particular stages. It's all about test automatisation and early verifications of the code. In my next article I plan to share some more tips on have to save time and energy of the developers’ by smart use of automation programming.