Blog entries

New apycot release

2008/06/02 by Arthur Lutz
http://www.logilab.org/image/4878?vid=download&small=true

After almost 2 years of inactivity, here is a new release of apycot the "Automated Pythonic Code Tester". We use it everyday to maintain our software quality, and we hope this tool can help you as well.

Admittedly it's not trivial to setup, but once it's running you'll be able to count on it. We're working on getting it to work "out-of-the-box"...

Here's what's in the ChangeLog :

2008-05-19 -- 0.11.0
  • updated documentation
  • new pylintrc option for the pyhton_lint checker.
  • Added code to disabled checker with missing required option with the proper ERROR statut
  • removed the catalog option of the xml_valid checker this feature can now be handle with the XML_CATALOG_FILE environement variable (see libxml2 doc for details)
  • moved xml tool from python-xml to lxml
  • new 'hourly' mode for running tests
  • new 'test_activity_report' report
  • pylint checker support new disable_msg and show_categories options (show_categories default to Error and Fatal categories to avoid reports polution)
  • activity option "days" has been renamed to "time" and correspond to a number of day in daily mode but to a number of hour in hourly mode
  • fixed debian_lint and debian_piuparts to actually do something...
  • fixed docutils checker for recent docutils versions
  • dropped python 2.2/2.3 compat (to run apycot itself)
  • added output redirectors to the debian preprocessor to avoid parsing errors
  • can use regular expressions in <pp>_match_* options

apycot 0.12.1 released

2008/06/24 by Arthur Lutz

After one month of internship at logilab, I'm pleased to announce the 0.12.1 release of apycot.

for more information read the apycot 0.12.1 release note

You can also check the new sample configuration.

Pierre-Yves David


Apycot big version change

2009/01/26 by Arthur Lutz

The version convention that we use is pretty straight forward and standard : it's composed of 3 numbers separated by dots. What are the rules to incrementing each on of these numbers ?

  • The last number is a incremented when bugs are corrected
  • The middle number is incremented when stories (functionalities) are implemented to the software
  • The first number is incremented when we have a major change of technology

Well... if you've been paying attention, apycot just turned 1.0.0, the major change of technology is that it is now integrated to CubicWeb (instead of just generating html files). So for a project in your forge, you describe the apycot configuration for it, and the tests for quality assurance are launched on a regular basis. We're still in the process of stabilizing it (latest right now it 1.0.5), but it already runs on the CubicWeb projects, see the screenshot below :

http://www.logilab.org/image/7682?vid=download

You should also know that now apycot has two components : the apycotbot which runs the tests and an cubicweb-apycot which displays the results in cubicweb (download cubicweb-apycot-1.0.5.tar.gz and apycotbot-1.0.5.tar.gz).


L'intégration continue présenté par Agiles Nantes

2010/03/18 by Arthur Lutz

Hier, Logilab était à nouveau présent aux rencontres organisées par Agiles Nantes, il s'agissait d'une présentation très fournie sur l'intégration continue (présenté par la société Netapsys). Malheureusement, la principale technologie utilisée était Java dont nous ne sommes pas des grands fans, préférant python. Néanmoins cela donne une bonne idée des possibilités qu'offrent les outils autour du développement java, notamment en terme d'intégration continue (voir Maven, Hudson, Sonar, etc.).

http://hudson-ci.org/images/butler.png

On retrouve donc un certain nombre de similarités avec le monde python, notamment avec Artifactory qui reproduit en partie les fonctionnalités de pypi avec easy_install ou buildout ou apt-cacher-ng dans son coté proxy. A Logilab, nous privilégions l'utilisation de paquets debian pour distribuer nos logiciels, ce qui permet, notamment, de ne pas réinventer la roue pour chaque langage de programmation.

Voici quelques une des notions avancées lors de la présentation qui nous semblent intéressantes sur l'intégration continue :

  • celle-ci permet de mettre en place des environnements de test mis à disposition du client tout le long du projet.
  • cette notion de prototype utilisable en continu doit être présente le plus tôt possible dans un projet.
  • idéalement, un serveur de déploiement/intégration doit être quasiment à l'identique de l'environnement client (utilisation de machines virtuelles)
  • l'intégration continue est souvent plus utilisées par les développeurs et les chefs de projets que par les clients. Mettre en place des rapports utiles au client requiert un soin particulier
  • pour une émulation collective, certaines notations des développeurs sont possible. Par exemple un plugin Hudson donne un point par build réussi, un point par test ajouté, moins dix points pour un build cassé.
  • la visualisation des données peut motiver les développeurs, l'outil Sonar semble être très complet et propose des visualisation assez léchées. A noter, des graphes sur la complexité du code, par classe, par méthode etc. Voir aussi la visualisation de l'arbre des dépendances des librairies avec Radiator.
http://sonar.codehaus.org/wp-content/themes/sonar/images/dashboard.png

J'y ai mentionné apycot et buildbot qui sont tous les deux des outils plutôt orientés python (mais pas seulement).

Pour conclure, tout ça m'a fait penser au concept plus poussé de "Continuous Delivery - BlueGreenDelivery" développé par Martin Fowler, une lecture recommandée pour ceux qui ont déjà pris le pas de l'intégration continue.

http://www.martinfowler.com/bliki/images/blueGreenDeployment/blue_green_deployments.png