Vers une centralisation des services d’hébergement de projets de développement?

Je change la routine. Mes billets habituels sont informatifs, avec celui d’aujourd’hui j’espère créer une discussion afin de connaître de savoir ce que mes lecteurs en pensent.

website-647013_640Si vous êtes à l’affut des blogs techno, vous avez possiblement vu, la semaine dernière, l’annonce de Google qui a décidé de fermer son service Google Code à partir de janvier 2016. Si vous n’êtes pas au courant, voici un petit topo : il n’est déjà plus possible de créer de nouveaux projets, à partir du mois d’aout 2015, l’ensemble du site et des dépôts de code seront en lecture seule et, le 25 janvier 2016, le site sera complétement fermé.

La raison avancée par Google est honnête. En 2006, au moment de la mise en ligne de Google Code, il n’existait pas, sur le marché, de service de qualité pour l’hébergement de projet de développement. Aujourd’hui, le portrait est bien différent, il existe deux géants qui héberge la grande majorité des projets de développement sur le web : GitHub et Bitbucket. Ces deux services sont solides, abordables et extrêmement conviviaux donc pourquoi s’entêter à offrir un produit avec moins de fonctionnalités? Je crois que la décision de Google est la bonne.

Quelle est la suite des choses sur le marché? On remarque une tendance similaire chez Microsoft. Au cours des derniers mois, Microsoft a diffusé sous licence open source plusieurs éléments majeurs de son stack technologique : .NET Core 5, ASP.Net 5, Roslyn, EF, etc. Tous ces produits et biens d’autres projets importants pour Microsoft (Pattern and practices pour SharePoint par exemple) ont été publiés CodePlex (le site d’hébergement de projets de Microsoft)? Non, la compagnie de Redmond a plutôt optée pour utiliser GitHub. Dans cette optique, je crois sincèrement que les jours de CodePlex sont comptés et qu’une annonce de Microsoft à ce sujet viendra dans les prochains mois.

Qu’en est-il pour le futur de Team Foundation Server? Il serait nettement exagéré de croire que TFS sera abandonné par Microsoft et que le produit sera remplacé par GitHub. Le produit est trop important et offre un éventail de fonctionnalités trop large pour qu’une solution aussi drastique soit envisagée. On note cependant une intégration de plus en plus forte entre Visual Studio et les «repository» Git depuis la version 2012. Est-ce que, sans faire disparaître TFS, on pourrait voir un rapprochement avec la technologie Git au cours des prochaines années? Je n’ai pas la réponse mais n’hésitez pas à laisser vos commentaires ou vos prédictions sur le sujet.

Et si on utilisait la recherche… pour plus.

Les fonctionnalités de recherche sont une partie intégrante de SharePoint depuis plusieurs versions. Les outils étaient présents dans MOSS 2007 et on pouvait déjà les étendre en y ajoutant Microsoft Search Server 2008. L’intégration de la recherche d’entreprise dans SharePoint 2010 et la possibilité d’y ajouter les capacités de FAST ont encore fait progresser les capacités. Finalement, la venue de SharePoint 2013 intégrant directement les aspects de FAST, les «display templates» et bien d’autres fonctionnalités permettent maintenant à la plateforme d’offrir aux usagers et aux administrateurs des capacités de repérage des actifs informationnels très évoluées. Mais est ce que la recherche doit nécessairement se limiter au traditionnel processus de saisie de mots clés afin d’obtenir une liste de résultats? La réponse est non et voici quelques exemples.

Annuaire d’entreprise

Faire plus avec la recherche
L’annuaire d’entreprise est une fonctionnalité qui peut être mise en place aisément dans SharePoint 2013 et qui offre une valeur d’affaire incroyable à l’organisation. Le processus est simple, utiliser l’application des profils usagers de SharePoint pour synchroniser les données à partir de Active Directory (ou d’autres sources) et le service de recherche afin de permettre de repérer très rapidement l’information. Le centre de recherche d’entreprise offre, à la base, la recherche de personnes. Il n’y a cependant aucune obligation de se limiter à l’affichage de type «résultats de recherche» par défaut. À l’aide des «display templates» intégrés à la recherche SharePoint 2013, il est très simple de modifier le rendu final pour l’afficher, par exemple, en format tabulaire, y inclure des données supplémentaires et pour permettre à l’usager de trier les résultats selon les propriétés qu’il juge pertinentes.

Le CSWP et l’affichage dynamique du contenu

Aussi, SharePoint 2013 introduit une nouvelle fonctionnalité pour les utilisateurs, le «Content search web part» (CSWP). Les capacités de ce contrôle sont immenses. En effet, en utilisant uniquement quelques modifications «front-end» pour ajuster le visuel (sans aucun code serveur), vous êtes en mesure de présenter l’ensemble des données présentes dans votre infrastructure SharePoint de la façon que vous désirez. C’est une capacité qui était présente, avec plusieurs limitations, dans les sites de publication SharePoint depuis la version 2007 grâce au «Content query web part» (CQWP). Le CSWP résout les deux lacunes principales de son prédécesseur, c’est à dire que le CQWP peut obtenir uniquement les données dans la collection de sites courante et que la personnalisation de l’aspect présentation est complexe et doit se faire en XSLT.

Faire plus avec la recherche 2Le CSWP, comme son nom l’indique, utilise les résultats d’une requête de recherche paramétrable, afin de présenter l’information pertinente (et contextuelle) à l’usager. La requête peut accéder une multitude de sources d’informations incluant tous les sites SharePoint, d’autres sites web (externes à SharePoint), des fichiers sur un partage, des données provenant d’un système de mission et bien d’autres. L’aspect visuel du CSWP est géré à travers les «display templates», donc en HTML et Javascript. Cette portion est donc beaucoup plus simple que la façon traditionnelle en XSLT.

En utilisant le CSWP, il est maintenant possible de construire un site portail, regroupant l’information de plusieurs sources (les actualités, annonces du club social, les anniversaires, les offres d’emploi, les éléments consultés fréquemment, etc.) en exploitant uniquement la recherche, les «display templates» et en éliminant presque 100% du développement traditionnel (.NET). Cette façon de faire permet de diminuer grandement le temps de développement, la complexité de gestion du code source ainsi que les efforts nécessaires pour l’entretien du site à travers le temps.

Intelligence d’affaire et tableaux de bord

Parallèlement, quand on parle d’intelligence d’affaire, on imagine souvent des plateformes complexes permettant de faire du «BI» à l’échelle des grandes organisations. Des solutions de «BI» d’une envergure plus modeste peuvent cependant être d’une grande valeur pour de plus petites entreprises (et même les plus grandes). Encore une fois, les fonctionnalités de recherche de la plateforme SharePoint 2013 peuvent répondre à ce type de besoins.

Lors d’un mandat, un partenaire désirait mettre en place une série de sites de projets basée sur un modèle standardisé. Chaque site devait comprendre un certain nombre d’informations sur l’état d’avancement du projet et celles-ci étaient présentées à l’équipe lors de la consultation page principale du site. En parallèle, l’équipe de direction souhaitait avoir une vision globale leur permettant de repérer rapidement les problèmes lorsqu’un projet présentait des signes de difficulté ou de retard. La proposition retenue afin de combler le besoin de la direction s’est donc appuyée sur les composantes de recherche, spécifiquement le CSWP, afin d’exécuter des requêtes précises sur les métriques de chaque projet et de présenter cette information sous forme de tableaux de bord (visuel et graphiques réalisés à l’aide de «display templates») dans un site réservé à la direction. La mise en place de ce type de solution est très rapide, exploite l’actif SharePoint déjà présent dans l’organisation et ne nécessite pas l’acquisition et l’implantation de solutions de «BI» coûteuses.

En résumé, la recherche de SharePoint est beaucoup plus qu’un simple champ texte et un résultat de recherche. Avec les améliorations à la plateforme (principalement dans la version 2013), la recherche de SharePoint est réellement un outil d’entreprise de grande valeur qui vous permet de regrouper l’information, extraire les éléments pertinents et les présenter comme vous le désirez sans nécessiter de développements complexes.

 

Développement SharePoint… sur Amazon!?!

Les solutions pour mettre en place des environnements de développement SharePoint sont multiples. Avec quelques collègues, nous avons récemment réfléchi pour trouver une solution abordable et flexible. Voici quelques critères que nous avons identifiés :

  • permet d’avoir autant d’environnements SharePoint que nécessaire;
  • permet d’avoir accès à un domaine central (pas attaché à l’une ou l’autre des machines de développement);
  • avoir un coût mensuel raisonnable;
  • ne nécessite pas l’installation de serveurs physiques;
  • est performante;
  • disponible partout;
  • ne nécessitant pas d’avoir une machine physique très performante (et très lourde dans le cas d’un portable).

Après avoir analysé les diverses pistes de solution, Metalogique a décidé d’opter pour une infrastructure dans le cloud basée sur l’offre d’Amazon. Dans un premier temps, nous avons mis en place un VPC permettant d’avoir un réseau privé dans le cloud d’Amazon et de permettre la communication entre les diverses machines par leur interface réseau privé. Ensuite j’ai fait l’installation d’un contrôleur de domaine et d’un serveur TFS en utilisant des instances EC2 de petite taille. Ces deux serveurs roulent 24/7 et sont suffisamment performants pour notre équipe d’une dizaine de développeurs.

Ensuite, chaque développeur peut gérer sa (ou ses) machine de développement SharePoint. La configuration initiale de celle-ci est entièrement scriptée et prend moins d’une heure. On utilise des instances r3.large (6.5 ECU, 15GB ram) qui sont très performantes et relativement économiques (0.30$ / h incluant Windows et SQL Express). Il est aussi très facile d’augmenter la capacité d’une instance dans le cas où cela serait nécessaire.

Un seul problème avec cette solution. Si les machines de développement roulent 24/7, on paie entre trois et quatre fois trop cher car les employés ne les utilisent que 7-8h par jour. À moins de donner l’accès à tous les employés à la console de gestion Amazon (avec tous les droits sur le compte), il est impossible pour un développeur d’arrêter ou de démarrer son instance à la demande.

Encore une fois, la solution est assez simple. J’ai développé une application web MVC .NET utilisant le SDK AWS .NET afin de se connecter au compte AWS de Metalogique et de présenter au développeur uniquement les machines lui étant assignées (en utilisant les tags). Le développeur n’a qu’à se connecter à l’application MVC, et démarrer ou arrêter sa machine au début ou à la fin de sa journée de travail.

Il serait également possible d’automatiser le démarrage ou la fermeture des instances selon un horaire prédéfini, mais la solution actuelle convient à nos besoins pour le moment.

Depuis l’implantation, la solution fonctionne très bien. La performance est intéressante, on peut se connecter en RDP aux machines de n’importe où, le coût est accessible à une PME, pas besoin de faire l’entretien de serveurs physiques, plus besoin de trainer un portable de 15lbs (vive les ultrabooks) et ça peut fonctionner avec d’autres applications (j’ai récemment créé une instance Linux pour un collègue en mandat).

Je vous invite à me contacter si vous avez des questions ou des commentaires. Si l’intérêt est là, je ferai un autre billet sur les aspects plus techniques de la configuration.

Lien vers un formulaire de propriétés Modal dans SharePoint

Historiquement, les formulaires NewForm.aspx, EditForm.aspx et DispForm.aspx étaient accessibles directement en effectuant un hyperlien sur celui-ci. Depuis la version 2010, nous avons l’option proposée est une fenêtre Modal (Popup) et pour plusieurs d’entre nous, il est impossible d’effectuer un lien vers notre formulaire Modal. Nous sommes donc contraint de remettre le bon vieux formulaire aspx pour pouvoir par la suite faire pointer un lien sur celui-ci..

Voici donc la « Recette à suivre » pour établir un lien vers une fenêtre modal

  1. Naviguer à la page ou vous souhaitez mettre le lien
  2. Ajouter un WebPart « Éditeur de contenu » ou « Éditeur de script »
  3. Ajoutez le bout de code ci-bas dans l’éditeur de script

<script type= »text/javascript » src= »/_layouts/15/sp.runtime.js »></script>
<script type= »text/javascript » src= »/_layouts/15/sp.js »></script>

<script type= »text/javascript »>

function dialogfunction(pageUrl) {
var options = { url: pageUrl, width: 540, height: 800 };
SP.SOD.execute(‘sp.ui.dialog.js’, ‘SP.UI.ModalDialog.showModalDialog’, options);
}
</script>

Ajouter votre lien Html tel que ci-dessous en prenant soin de remplacer

  • URL DE VOTRE LISTE
  • URL DE RETOUR
  • NOM DU LIEN

<a href= »# » unselectable= »on » onclick= »dialogfunction(‘URL DE VOTRE LISTE/NewForm.aspx?Source=URL DE RETOUR&RootFolder=’) »>NOM DU LIEN</a>

Les 5 raisons derrière l’échec des projets TI

C’est bien connu et en même temps toujours embarrassant de le rappeler, de trop nombreux projets TI connaissent de sérieux ratés et dépassent, parfois largement, échéancier et budget.

Chart going through the floor

Le site Technovation Talks nous propose sa liste des « Top 5 Reasons IT Projects Fail ».

Voici le résumé que le site Trends in the Living Networks en a fait:

1. An inability to examine or challenge assumptions: Most terminal problems will show up in the initial stages of the project, and they continue to progress because no one speaks up.

2. A “silo” mentality: This means a project that becomes over-compartmentalized. Not only do teammates cease to work together, but they start to point fingers when things go wrong.

3. The inability to compromise: In order to succeed, your project has to be flexible, and it won’t be unless the people behind it are as well. If you fail to compromise, deadlines are going to quickly pass you by.

4. Technology-Centric Projects: Are you using the next big thing in technology because you need it or because everyone else is using it? Remember the point of these products is not just to look cool, but to align to your organization’s needs.

5.  Poor Role Definition and Project Dynamics: Don’t get confused with who’s doing what. Make sure jobs are clearly defined. Leaders should be flexible, but everyone still needs one person to take charge.

Pour plus de détail, le billet original se trouve  ici.

Pratiques de développement: impliquer, tester et livrer… toujours!

Le site VENTUREBEAT nous présentait, récemment, un article sur les 10 meilleures pratiques à adopter selon plusieurs leaders du marché, se basant sur de grandes entreprises telles que Google et Pinterest. Ces recommandations sont très intéressantes d’un point de vue développeur et cela m’a donné envie de ressortir les éléments s’adressant à tous les acteurs dans un projet TI. Résultat : trois recommandations : impliquer, tester et livrer…

Impliquer tout le monde
Dans un contexte de consultation, il est souvent difficile d’impliquer et d’informer les différentes ressources dans l’ensemble d’un projet, car celles-ci vont et viennent au gré des divers contrats.

Considérant cet enjeu, il est capital d’utiliser une approche permettant de diffuser la connaissance et de recueillir l’avis et les commentaires de toute de l’équipe de façon régulière, idéalement sur une base quotidienne.  Cette approche, en plus de permettre une gestion plus serrée des problèmes, permet aussi d’augmenter l’implication et le sentiment d’appartenance des divers acteurs impliqués.

L’intégration d’une méthodologie de type agile permet aussi la révision des besoins et la mise en place de correctifs plus rapidement, permettant d’éviter certains dérapages coûteux, particulièrement dans les projets gouvernementaux où l’étendue de ceux-ci est grande et le nombre d’acteurs est souvent élevé.

Tester tout
Depuis quelques années, l’utilisation des tests automatisés s’avère un incontournable à la réalisation d’applications de qualité. Il est extrêmement coûteux (en temps, en argent et en motivation) de refaire manuellement les tests unitaires pour chaque modification mineure du code. Les tests automatisés deviennent donc un «must» si on veut livrer un logiciel de qualité, en respectant le budget et les échéanciers.

Un bon mantra à adopter pourrait être «Ne jamais repousser les tests». Il est impératif d’atteindre une couverture de code de 100% avec les tests unitaires automatisés et de maintenir ce niveau de couverture tout au long de l’évolution de l’application. Il est beaucoup trop facile pour un développeur ou un chargé de projet, notant un retard dans les échéanciers, de repousser la réalisation des tests. C’est absolument à proscrire car les tests ne se réaliseront probablement jamais et le risque d’introduction de bugs dans le code s’accentue.

Les tests automatisés permettront aussi d’identifier les problèmes potentiels et les bugs plus tôt dans le cycle de développement. Comme le mentionne Jeremy Green dans l’article de VentureBeat: « Early bugs are usually easy bugs. »

Des spécialistes en assurance qualité (QA) doivent aussi faire partie de l’équipe de projet afin de réaliser les tests de haut niveau. Les spécialistes QA doivent être impliqués et avoir un sentiment d’appartenance au projet afin d’éviter des frictions avec le reste de l’équipe et des délais inutiles. Il est capital de ne pas confier la réalisation de l’ensemble des tests à l’équipe de développement, ceux-ci étant trop familiers avec l’application pour réaliser certains jeux d’essais comme, par exemple, les essais fonctionnels.

Livrer tout le temps
On le voit depuis plusieurs années déjà, les cycles de livraison des produits, sites web et apps sont de plus en plus courts. Certaines compagnies se dirigent vers des produits où les numéros de version disparaîtront complètement pour l’usager (pensons entre autre aux produits Office online pour lesquels Microsoft vise une mise à jour deux fois par an comme le rapporte ce billet paru sur le site c|net.

La tendance du marché est claire, on doit livrer plus rapidement. On doit découper une application en composantes unitaires et livrer une nouvelle version pour chacune de ces composantes. Chacune de ces livraisons doit cependant être testée, documentée et présentée au client. Grâce à ces livraisons rapides, le client sera en mesure d’acquérir de l’expérience dans votre application dès le début, réduisant ainsi les besoins en formation. Mais principalement, cela donnera une base de discussion entre le client et l’équipe de développement qui vous permettra d’identifier les éléments applicatifs qui ne répondent pas correctement aux attentes du client et de les corriger rapidement, sans impacts majeurs sur l’architecture du logiciel. Cet aspect est très bien expliqué par Stephanie Volftsun :

«Fail Fast. In coding (and in life), I want to know at the earliest possible point that something is broken or not working, rather than let it sit and propagate further. Go all in, fail quickly, fix what’s broken, and keep on keeping on»

Il est clair que les clients d’applications en 2013 sont beaucoup plus demandants qu’ils ne l’étaient il y a dix ou même cinq ans. Les utilisateurs sont habitués à des applications de qualité, sans bug, rapides et qui évoluent rapidement afin d’intégrer de nouvelles fonctionnalités. Si une équipe n’est pas en mesure de répondre à ces demandes de sa clientèle, son application n’aura tout simplement pas le succès escompté.