Sunday, October 21, 2012

Developemnt environment - Part I


Development environment - Part I

The objective of this series of posts, is to figure out an environment for developing cross-platform multi-targeted (desktop and web, SaaS, front-end and back-end parts) and multi-lingual (C++, Python, Java, JS) applications using TDD as quality control and Continues Delivery to release faster and more frequently. This post is mostly for my own reference, but you may find it useful as well (or comment on what I did wrong :) ). I hope that this series of posts will initiate a discussion on this topic, where everybody will participate to figure out best layout.

In this first post, I want to describe requirements in deep, and then step by step in next posts build a system that will satisfy them.

So, let’s again describe requirements, that environment should satisfy:
1) Software will be cross-platform: Windows, Linux, FreeBSD, Mac OS, HP-UX, AIX, iOS, Android.
This also adds additional plane for thinking - people want to use best IDEs that are available in concrete platforms. For example for development in C++ at Windows - Visual Studio will be the best choice, and developers wouldn’t want to downshift to Eclispe or other cross-platform, but less developer-friendly systems.
2) Software will be multi-targeted: application will have back-end and front-end sides, each of which can be run on multiple platforms - back-end may be running on desktop, server or cloud, when different front-ends will be running on desktops and in the web.
3) Multi-lingual: Lowest level of back-end will be running on C++ to achieve best efficiency, when higher levels of back-end may run on Python (faster development, less code). Front-end may be containing Java and\or JS (desktop and web).
4) System should be extensively tested on regular bases (best if after each commit) by unit-tests, integration tests, performance tests.
5) System should provide Continues Delivery, that will allow to put a feature to production at the same day as it was finished (passed all tests as well) and allow users give a feedback about it. But if one of new features did brake build - this shouldn’t stop other new features from be released.
6) Environment should have outline behaviour for teams of different size and on different stage of development. (Example, at the beginning when couple people may work on same component, and they should work in the same branch, on the other hand at feature-creep stage - each person works on separate small\medium size feature and should work in own branch).

If we go for more detailed numbering of IDEs on each platform:

  • Windows: 
    • Visual Studio for C++;
    • Notepad++ for Python, JS;
    • Vim for C++, Java, Python, JS;
    • Eclipse for C++, Java, Python, JS;
    • QtCreator for C++.
  • Linux: 
    • Vim for C++, Java, Python, JS; 
    • Eclipse for C++, Java, Python, JS;
    • QtCreator for C++.
  • Mac OS: 
    • Vim for C++, Python, JS; 
    • Eclipse for C++, Java, Python, JS; 
    • XCode for C++;
    • QtCreator for C++

As we see, Eclipse is pretty universal IDE, as well as vim. But developers are different in nature, and some want to get the best tools and development experience money can buy on each platform - i.e Visual Studio for Windows, XCode for Mac OS. Others, will tolerate “common” denominator and would want to work in universal development environment. Some, will enjoy using QtCreator which is cross-platform and pretty good for C++.
In result, we want our solutions\projects to be generated from single source to multiple destinations (VS projects, Eclipise projects, and support QtCreator) and be able to work with plain make system as well.

Quality of build is very important especially if Continues Delivery required. To ensure that the fresh build is qualitative, next activities should be performed:


  • Static code analysis to straighten out code and prevent issues.
  • Unit tests (each piece of functionality should be tested; should be fast and not involve any external components or services (no filesystems, databases etc))
  • Component tests (each component should be tested as combination of units)
  • System tests (multiple comonents working together)
  • Functional tests (testing functionality from user’s perspective\user stories)
  • Load and performance tests (to ensure speed and stability)
  • Issues and bugs should be translated to appropriate type of tests.
  • Code-coverage to ensure that functionality is tested
  • Deployment to staging environment, where system can be tested by QA or by subset of customers.


List of performed activities can be increased if needed. As well as requirements will be more detailed over time.
If somebody see that I missed something - please leave a comment.

UPD. QtCreator added from Vlad's comment.