Plan and ideas for migration

Here we try to think about a plan to start implementing Autodiag 2, the revenge of the new engine.

From what we can see there is some differences between Inserdiag and Culturdiag.

Culturdiag have allready been implemented through Autodiag 1.

  1. Backport Inserdiag unique features into Autodiag 1, then implement Inserdiag using it, this way we have a consolidated engine for all plateforms.
  2. Then we can start to mind about API changes and finish its unittests for maximum API coverage;
  3. Finally we can continue on the webapp components to do the rest;

This plan should be improved through further progress.

Sample part

  • ☐ To do;
  • ☑ Done;

Chapter 1 - Freeze the Mammouth

  • ☑ Move last xml2xsl version (using xslx only) into autodiag app;
  • ☑ Enable a console_script for xml2xsl into autodiag ?
  • ☑ Release Autodiag as 1.0;

Chapter 2 - Evolving to Elephant

  • ☑ Open a branch 2.x for Autodiag;
  • ☑ Open a branch 2.x for Culturdiag for Autodiag 2.x implementation;
  • ☑ Open a branch 2.x for Inserdiag for Autodiag 2.x implementation;
  • ☑ Prepare Inserdiag data migrations to Autodiag (add missing model elements from Culturdiag, add south migrations and raw sql migrations);
  • ☑ Implements Inserdiag specific features into Autodiag 2.x;
  • ☐ Implement Autodiag project structure into Inserdiag;
    • ☑ Adapt matrix stuff into apps/inserdiag_matrix;
    • ☑ Move all workbooks global vars to settings;
    • ☑ Adapt templates and static structure;
    • ☑ Add bases matrix stuff (base graph, base modified, etc..) like in culturdiag;
    • ☐ Bug fixes to stabilize plateform;
  • ☐ Redo migrations scripts for Inserdiag datas into Autodiag structure;

Various tasks in loose order

Here are some extra bonus tasks that would be nice to be done when

  • ☐ Start new extractor system with Openpyxl;
  • ☐ Move css into a compass dir(s?);
  • ☐ Try to merge User profiles and related user kind models to avoid too much db requests and painfull code;
  • ☐ Totally remove dependancies to Sveetchies package;
  • ☐ Upgrade Django to 1.6 (through passing to 1.5 before?), through 1.4 is nice for now because it’s a long time support (before 1.8 is released);
  • ☐ Refactoring forms to use crispy-forms instead of sveetchies prototypes forms;
  • ☐ Mind about writing also some extra unittests for the matrix part into API;
  • ☐ Better API unittests with PyTest;
  • ☐ ...?
  • ☐ Profit!

Branches explain


Got two distinct branches:

  • master for Autodiag 1.x;
  • moving_to_2-0 for on work Autodiag 2.x;

Use branches:

  • master for Autodiag 1.x, it’s a stable release for current production until 2.x is validated;
  • support_autodiag_2-0 for the 2.x using Autodiag branch moving_to_2-0;

Use branches:

  • master is actually freezed on its last stable release on production, that does not use Autodiag;
  • move_to_autodiag_2-0 is the step move to prepare data migration from production (on master) for migrating plateform to Autodiag (it still not using it just prepare some models for data migration with South);
  • autodiag_ready is the final step for migrating to the plateform using Autodiag branch moving_to_2-0;


Autodiag is a real Python package but private and so can not be released on PyPi server for privacy and licensing issues.

So buildout configs that relies on it (Culturdiag and also Inserdiag on its autodiag_ready branch) are using it as a vcs package, meaning as a development source.

It conducts to buildout installing it directly from our private repository, but only when it does not allready exists (to avoid to lose local changes from developer).

Finally, it means that you MUST go to your installed Autodiag repository directory (in django-apps-src) then pull it every time you update the plateform and required Autodiag version has changed in versions.cfg. Note that the vcs dont (or should?) not take care of real pulled version and required version, it may pull a more recent version although the required one is more old.