Versions
Nous avons développé deux versions de notre plugin.
La Community Edition est gratuite. Elle cible le respect des bonnes pratiques de développement.
L’Enterprise Edition ajoute à la Community Edition un support utilisateur gratuit et des règles ciblant les bugs et les problèmes de performance.
Pour télécharger la Community Edition, rendez-vous sur la page de téléchargement.
Pour en savoir plus sur l’Enterprise Edition, contactez-nous.
| Règle | Community Edition | Enterprise Edition |
| Un job devrait contenir une « Description Annotation » | x | x |
| Tous les jobs devraient se trouver dans une même catégorie | x | x |
| Le design du job devrait respecter une dimension maximale | x | x |
| Un même fichier de sortie ne devrait pas être référencé plusieurs fois dans un job | x | |
| Le contenu de la « Short Description » devrait être archivé dans la « Full Description » | x | x |
| Les entrée du job devraient être alignées à gauche du design | x | x |
| Le nommage d’un job devrait respecter la convention | x | x |
| Les sorties du job devraient être alignées à droite du design | x | x |
| Les sources de données de référence devraient être alignées en haut du design | x | x |
| Les cibles de rejet devraient être alignées en bas du design | x | x |
| Le champ « Short Descritpion » devrait être renseigné | x | x |
| Le champ « Short Description » devrait respecter le format défini | x | x |
| Le champ « Short Description » devrait utiliser le numéro de version défini dans le job | x | x |
| Un job ne devrait pas contenir trop de stages | x | x |
| Tous les jobs devraient se trouver dans une sous catégorie | x | x |
| Le design d’un job devrait être connexe | x | |
| Les flux principaux devraient être tracés horizontalement, de gauche à droite | x | x |
| Le nommage d’un lien devrait respecter la convention | x | x |
| Le partitionnement « Auto » ne devrait pas être utilisé | x | |
| Le partitionnement Hash ne devrait pas être utilisé sur une clef de type Integer | x | |
| Les partitionnements successifs ne devraient pas être redondants | x | |
| Les flux de référence devraient être tracés verticalement, de haut en bas | x | x |
| Les flux de rejet devraient être tracés verticalement, de haut en bas | x | x |
| Les tris successifs ne devraient pas être redondants (2 liens) | x | |
| Les tris successifs ne devraient pas être redondants (1 lien / 1 stage) | x | |
| Toutes les colonnes d’une entrée ou d’une sortie doivent utiliser la même TableDef | x | x |
| Quand une colonne déclare l’utilisation d’une table def, le format doit correspondre à la définition de la table def | x | x |
| Toutes les colonnes de la table def doivent être présentes dans le lien d’entrée ou de sortie l’utilisant | x | x |
| Les liens d’entrée et de sortie doivent utiliser une table def | x | x |
| L’option « unique » d’un tri ne devrait pas être utilisée | x | x |
| Tous les éléments d’un job devraient être présents dans le même export | x | x |
| Le nom du projet devrait respecter la convention | x | x |
| Un export ne devrait pas compter trop de composants | x | x |
| Un export devrait être réalisé à partir du serveur de développement | x | x |
| La méthode de calcul « Sort » de l’aggregator devrait être utilisée | x | |
| Un partitionnement devrait être réalisé en amont de l’aggregator | x | |
| Un tri devrait être réalisé en amont de l’aggregator | x | |
| Le nommage d’un stage devrait respecter la convention | x | x |
| Un job ne devrait pas contenir de stage Peek | x | x |
| Le tri du stage ne devraient pas être redondant (avec un autre Stage) | x | |
| Un stage Sort ne devrait pas trier son lien d’entrée | x |