Invenietis (et Civikey) se montrent sur Pinpoint

Pinpoint

Cela fait maintenant plusieurs années qu'Invenietis fait partie du Microsoft Partner Network, mais nous n'avons jamais pris le temps de nous publier sur Pinpoint !!

Petite explication sur Pinpoint, c'est un annuaire fourni par Microsoft pour aider à trouver des partenaires ainsi que des outils pour les plateformes Microsoft. Vous pouvez retrouver ce portail ici :

Invenietis

Nous avons engagé la procédure de validation et publication d'Invenietis pour apparaitre dans cet annuaire il y a quelque temps et venons d'être validé. Vous nous trouverez dorénavant sur Pinpoint en cherchant un partenaire ou directement :

Civikey

Au fur et à mesure de son gain en maturité, le clavier virtuel open source et gratuit que nous développons avec l'aide de nos partenaires a de plus en plus besoin de se faire connaitre. Il est d'ailleurs disponible pour ceux qui ne le sauraient pas, à l'adresse suivante :

Nous avons pris l'initiative de continuer notre travail de certification et de visibilité de Civikey. D'une part, avec la certification de Civikey auprès de Microsoft et d'autre part avec la publication de Civikey sur Pinpoint.

Nous mettrons dorénavant un point d'honneur à certifier les différentes versions de Civikey auprès de Microsoft, les versions 2.7+ seront bientôt certifiées Windows 8 ! Pour rappel, les versions 2.6+ ont été certifiées Windows 7 dès leurs sorties. Je rédigerai un article à ce sujet quand le temps sera venu. 

La publication sur Pinpoint a été soumise à Microsoft et vient de passer l'ensemble des éléments de validation de Microsoft ! Ceux qui cherchent sur Pinpoint un "clavier virtuel" ou même juste un "clavier" dans la section applications, trouveront Civikey dans les premiers résultats:

La page de civikey :

La visibilité pour Civikey est primordiale et nous espérons que Pinpoint aidera à faire connaitre ce magnifique outil.

La suite

Ce petit travail de visibilité est loin d'être terminé aussi bien pour Invenietis que pour Civikey ou pour tout autre produit que nous sortirons plus tard, mais nous espérons nous améliorer rapidement sur ce sujet.

L’intégration continue avec Cruise Control .NET

Est-il nécessaire de présenter la notion d'intégration continue (Continuous Integration) ?

Le principe (en résumé) est le suivant : chaque fois que le développeur contribue au projet en ajoutant une mise à jour ou un fichier au dépôt central (on parle de commits), le projet est automatiquement recompilé, testé, et éventuellement délivré à nouveau.

C'est le travail du serveur d’intégration que d’automatiser ces tâches. En l'occurence, nous utilisons Cruise Control.Net que nous avons configuré pour supporter le principe d'organisation des codes sources mis en place dans le projet CiviKey et présenté précédemment.

Les quatres actions de base sont :

  1. Compilation en mode Debug
  2. Tests unitaires
  3. Compilation en mode Release
  4. Tests FxCop

Ces actions sont lancées après un commit (toute modification) dans :

  • /trunk
  • /releases/{VERSION}/trunk
  • /releases/{VERSION}/tags/{TAG}

Lors d’un commit dans /trunk il y a en plus une vérification du contenu du commentaire. S’il contient [DoRelease] ET que le fichier release.txt a été modifié (ie. il fait partie du commit - ceci est une sécurité) alors une nouvelle version sera créée automatiquement lors du commit (et donc une compilation du trunk de la version sera effectuée).

Le fichier release.txt se présente de la façon suivante :

# This file is used to generate a new Release branch.
# It contains:
# - ReleaseNumber: RELEASE-NUMBER (format X.X.X like 2.4.12 - major.minor.revision expected)
# - RevNumber: OPTIONAL-REVNUMBER-TO-RELEASE
# This is optional: it enables a "release from the past" if needed.
# By default, we take the SVN « RevNumber » of this file:
# since this file necessarily belongs to the commit, it is the current (the 'head' revision) /trunk version.

ReleaseNumber: 2.4.7

# RevNumber: 10 (Optional: to be used only if one want a Release based on a /trunk past version.)

Lors d’un commit dans /releases/{VERSIONS}/trunk il y a en plus une vérification du contenu du commentaire. Si il contient [Tag] ET que le fichier tags.txt a été modifié alors un tag sera créé dans cette version automatiquement lors du commit (et donc une autre compilation, mais de la version taguée sera effectuée).

Le fichier tags.txt se présente de la façon suivante :

# This file is used to generate a new Tag.
# It contains:
# - TagName: OPTIONAL-TAG-SUFFIX
# - RevNumber: OPTIONAL-REVNUMBER-TO-TAG
# This is optional: it enables a "Tag from the past" if needed.
# By default, we take the SVN « RevNumber » of this file:
# since this file necessarily belongs to the commit, it is the current (the 'head' revision) /releases/{VERSIONS}/trunk version.

TagName: Final

#RevNumber: 10

Lors de la création d’un tag /releases/{VERSION}/tags/{TAG} il y a la génération de l’aide correspondant à cette version (CHM + site web) ainsi que la génération du package pour cette version.

Grâce à tout cela, CiviKey est définitivement sous contrôle !

Organisation des Codes Sources du projet CiviKey

Nous avons vu dans un post précédant que le serveur SVN pour CiviKey était accessible via l’url http://svn.invenietis.com/svn/CK et que le serveur d’intégration continue était accessible à l’URL http://ci.civikey.invenietis.com/.

Dans ce post nous allons voir la gestion du repository SVN ainsi que de Cruise Control .NET pour le projet CiviKey. Ce qui est présenté ici n'est mis en place que pour la version 2.5 de CiviKey (celle sur laquelle nous concentrons actuellement nos efforts).

Le repository SVN

Le noyau de CiviKey est divisé en deux: le Core, qui contient le noyau proprement dit et Certified qui contient les plugins certifiés. L’architecture globale est la suivante :

Structure des fichiers de CiviKey

/CK Root du repository Svn de CiviKey
/CK/Core Projet CK.Core
/CK/Core/trunk Trunk des développements du projet CK.Core
/CK/Core/releases Dossier des releases de CK.Core (cf. ci-dessous)
/CK/Certified Projet CK.Certified
/CK/Certified/trunk Trunk des développements du projet CK.Certified
/CK/Certified/releases    Dossier des releases de CK.Certified
/CK/Document/trunk Ensemble des documents

Organisation des Versions

Les "releases" sont gérées à de la façon suivante. Le projet DEMO (qui est un projet similaire à Core) détaille l'organisation de l'arborescence des releases :

/trunk Trunk principale du Produit.
/releases Dossier contenant l’ensemble des versions du Produit.
/releases/VER Une des versions du Produit.
/releases/VER/trunk Trunk de développement permettant de corriger cette version.
/releases/VER/tags Dossier contenant l’ensemble des tags pour cette version du Produit.
/releases/VER/tags/TAGS Un tag contenant les sources a un certain stade.

Ce système nous permet de gérer au mieux la montée en version du projet tout en préservant la liberté du développeur. Et il y tient le développeur à sa liberté.

Une petite histoire

Les développeurs travaillent dans /trunk qui est l’espace de développement principal.
Ils font des évolutions, des changements dans l’API pour mettre en place les nouveautés, et, un jour une version est prête à voir le jour, les développeurs décident donc de créer une Version, disons la 2.5.0.

Un nouveau dossier est créé dans /releases : /releases/2.5.0/trunk. Une Version est née, elle n'est pas parfaite (elle va avoir besoin de quelques retouches pour être finalisée) et va donc évoluer et donner naissance à des Tags.

Le premier de ces tags s'appelle CTP (pour Community Technology Preview, il aurait pu s'appeler Alpha ou PreAlpha ou autre nom qui indique que ce n'est pas vraiment sec) : /releases/2.5.0/tags/CTP apparait dans l'arborescence. Noter que les codes sources dans /tags n'évoluent pas: ils représentent des clichés, des instantannés, du /releases/2.5.0/trunk qui leur a donné naissance. Le trunk bouge, les tags figent.

Cet espace permet aux développeurs de continuer à travailler dans /trunk et donc de continuer à faire évoluer le noyau, pendant que d’autres travaillent pour la Version /releases/2.5.0/trunk afin de régler les derniers bugs qui pourraient exister. Une fois les derniers bugs corrigés dans le /trunk les développeurs créent le tag /releases/2.5.0/tags/Final (et espèrent très fort éviter le petit frère /releases/2.5.0/tags/SP1).(Voir http://en.wikipedia.org/wiki/Software_release_life_cycle pour des exemples de noms de révision.)

Pendant ce temps les développeurs du /trunk se sont lancés dans la future version 2.5.1 et ont d'ores et déjà produit une release en Alpha ce qui signifie qu’un dossier /releases/2.5.1/trunk a été créé ainsi qu’un tag /releases/2.5.1/tags/Alpha.

Cette petite histoire nous amène au dépôt suivant :

Avec ce système la version d’un projet à une vraie existence : les corrections sont possibles sans (trop) d'interférences ce qui libère le développeur, qui sait clairement s’il peut imaginer de nouveaux bugs (/trunk) ou s’il doit réfréner sa créativité (/releases).

Infrastructure technique du projet CiviKey

Invenietis a mis en place, pour le projet open source CiviKey, une infrastructure complète de gestion de projet technique. Cette infrastructure va continuer d’évoluer dans le temps, mais la base décrite dans ce poste est en place. Un autre post sera dédié à la gestion du repository SVN (dépôt SVN en français) et du serveur d’intégration. Nous avons choisi de mettre en place un certain nombre de services que l’on retrouve dans un grand nombre de projets. Ces services ont été mis en place à l’aide d’autre projet Open Source et à des modules spécifiquement développés pour la problématique de CiviKey.

Gestion du projet

La gestion projet a été déléguée à un outil fonctionnant en Ruby, Redmine (http://www.redmine.org). Il est utilisé par Invenietis en interne pour la gestion de projet ainsi que pour le dialogue avec nos clients. Cet outil permet de gérer l’ensemble des tâches lié à un ou plusieurs projets en proposant une interface web simple et un environnement unique. (Pour ceux qui connaissent, c'est un Track simple, fonctionnel, et multi projet.)

Ce service est accessible via l’URL : http://civikey.invenietis.com/

Repository SVN

La gestion des sources a été déléguée à un serveur SVN sous Windows à l’aide de VisualSvn Server (http://www.visualsvn.com/server/). Ce serveur donne accès à l’ensemble des sources du projet CiviKey.

Compte tenu du refactoring (assez violent) en cours, les dépôts de la version 2.0 et 2.5 n’ont pas la même structure.

Version CiviKey 2.0 :

         Core : https://svn.invenietis.com/svn/CK/branches/Core-Summer09

         Contrib : https://svn.invenietis.com/svn/CK/trunk/Contrib

Version CiviKey 2.5 :

         CK.Core : https://svn.invenietis.com/svn/CK/Core/trunk

         CK.Certified : https://svn.invenietis.com/svn/CK/Certified/trunk

Un premier autre post sera dédié a la gestion du repository par rapport à la gestion des releases et des tags de version.

Service d’intégration continue

Pour garantir la qualité des éléments développée dans ce projet, nous avons mis en place un service d’intégration continue qui permet de faire un ensemble d’opérations à chaque commit de développeur. Ce service a été mis en place grâce à Cruise Control .NET (http://ccnet.thoughtworks.com/). Il permet entre autres de compiler en environnement contrôlé, de faire passer des tests unitaires plus spécialisés que sur les postes de développement ou encore de gérer les releases des projets.

Ce service est accessible via l’URL : http://ci.civikey.invenietis.com/

Cruise Control  génère aussi la documentation type MSDN pour chaque release taguée du projet. Elles sont disponibles ici : http://help.civikey.invenietis.com/.

Un deuxième autre post sera dédié à la gestion de Cruise Control par rapport à la gestion des releases.

 

Les modes de compatibilités d'Internet Explorer 8

IE8 intègre à présent un système de Mode permettant les évolutions futures des produits IE de Microsoft. Ces modes permettent de changer le comportement (et donc les fonctionnalités) du navigateur pour qu’il puisse afficher au mieux les pages des sites qui ne seraient pas prévus à l’origine pour IE8.

Tableau récapitulatif des modes supportés

IE5 Affiche le contenu comme le ferait IE7 en « Quirks Mode ». Ce mode est très similaire au fonctionnement de IE5 pour afficher les contenus. Utilisation du moteur JavaScript présent dans IE7 (JScript Engine Version 5.7 Quirks Mode).
IE7 Affiche le contenu comme le ferait IE7 en « Standard mode », que la page ait ou non une directive valide. Utilisation du moteur JavaScript présent dans IE7 (JScript Engine Version 5.7). Ce mode ne passe pas du tout l’Acid test 2 et arrive péniblement à 12% de l’Acid test 3.
IE8 Mode de fonctionnement proposant le plus haut support des standards sur Internet Explorer. W3C CSS 2.1, W3C Selectors API ainsi qu’un support limité du W3C CSS 3 (Working Draft). Utilisation du moteur JavaScript présent dans IE8 (JScript Engine Version 5.8). Ce mode passe l’Acid test 2 et a 20% à l’Acid test 3.
EmulateIE7      Affiche le contenu en utilisant le même principe que IE7 pour déterminer le choix de rendu entre le « Quirks Mode » et le « Standars Mode ». Suivant la directive présente dans le document, la page sera donc affichée à l’aide du mode IE5 (Quirks Mode) ou du mode IE7 (Standars Mode). Utilisation du moteur JavaScript présent dans IE7 (JScript Engine Version 5.7 ou 5.7 Quirks mode). Ce mode est le mode de compatibilité à préférer pour une très grande partie des sites.
EmulateIE8 Mode similaire à EmulateIE7. Internet Explorer utilise la directive présente dans le document pour choisir le mode de rendu entre le « Quirks Mode » et le « Standard Mode ». La page sera donc affichée à l’aide du mode IE5 (Quirks Mode) ou du mode IE8 (Standars Mode). Utilisation du moteur JavaScript présent dans IE8 (JScript Engine Version 5.8) ou du moteur JavaScript présent dans IE7 en Quirks Mode( JScript Engine Version 5.7 Quirks Mode).
Edge Mode de fonctionnement demandant d’utiliser le mode de compatibilité le plus haut possible. Si une nouvelle version de IE propose un nouveau mode, les pages en mode Edge utiliseront le nouveau mode du navigateur. Ce mode est déconseillé et n’est à utiliser que sur les environnements de test.

Attention ! Modes sauvages en liberté !

Par défaut, Internet Explorer utilise le mode EmulateIE8 pour afficher les pages qui viennent de la zone internet (« Internet Zone »). Par contre, les pages venant de la zone intranet (« Intranet Zone ») ou des contrôles WebBrowser utilisent le mode EmulateIE7 par défaut (par exemple, http://localhost/ vient de la zone intranet). Ces paramètres peuvent être changés.

Références :

Pour comparer avec les autres navigateurs (Acid test 3) :

Microsoft a mis en place un système de certification des sites pour le passage à IE8. Ce système permet au navigateur de savoir si le site sur lequel il va allé est validé pour IE8 ou pas et donc s’il faut proposer à l’utilisateur la possibilité de passé en mode compatibilité ou non. Les explications par rapport à ce système sont expliquées dans le lien suivant :

Le mode a un impact sur la chaine de caractère du « User Agent » de IE8 ainsi que sur les « Version Vector » qui servent aux codes conditionnels dans le JavaScript, dans les CSS ou dans les commentaires HTML. Normalement, ce changement n’a que peu d’impact sur un site web, cependant il est à prendre en compte.

Références :