Étiquette : Tests

Formation Pragmatik ALM and Devops with VSTS

Hello,

Début juin, j’ai profité d’une place libre dans la session de formation Pragmatik ALM & Devops with VSTS par la TC Agility & Devops d’Avanade. La session de 2 jours était organisée par Cidaline Freitas, galia training lead Avanade et les formateurs étaient Philippe Puschmann et Michel Perfetti dans les locaux (flambant neuf) Avanade.

Devops est un mouvement culturel qui vise à aligner les équipes d’un produit IT autour d’un objectif commun. Contraction de Dev et Ops, les Devs sont les équipes qui font évoluer le produit, les Ops sont les équipes qui opèrent le produit (infrastructure, réseau, exploitant…).

La formation est orientée ALM Application Lifecycle Management avec de nombreux ateliers (Hands-on) donnant lieu à de nombreuses discussions sur les autres aspects de Devops.

Au programme :

  • Visual Studio Team Services
  • Product Backlog Management
  • GIT
  • Continuous Integration
  • Continuous Deployment
  • Continuous End-to-End Testing
  • Powershell
  • Sprint Planning
  • Social Coding
  • Agile Test Planning
  • Test Run
  • Working with database projects
  • Load Testing

Avec ce programme adapté pour les Devs et les Ops, on aborde l’ensemble du cycle de vie de la création d’une fonctionnalité du besoin métier à la livraison de la fonctionnalité !

Au terme des 2 jours de formation, je suis reparti avec de nombreuses idées grâce aux différents sujets abordés avec les 2 formateurs. Je vous livre quelques mots clés de mes notes :

A bientôt,

Guillaume

Changement de datacenter / DC Move

Bonjour,

Depuis mon arrivée chez mon nouveau client, je suis intervenu sur de nombreux sujets comme le développement de datamarts ou la rédaction de spécifications. Ce sont des sujets assez courants dans le domaine du décisionnel.

Il y a quelques semaine, je suis intervenu sur un projet de changement de datacenter pour les serveurs de la BI. Il ne s’agissait pas du déplacement physique des machines mais logique. L’objectif était donc de gérer l’ensemble du processus de déplacement coté données et applications. La partie matérielle et OS était assurée par une équipe infrastructure.

Voici quelques problématiques que nous avons rencontré (la liste n’est pas exhaustive) :
– Continuité : Puis je me permettre de perdre une journée de données ?
– Volumétrie : Comment réaliser le transfert des données entre les 2 sites ?
– Bande passante : Quel serait le meilleur moment pour faire un transfert par le réseau ?
– Compatibilité : Est ce que la nouvelle architecture est la même que l’ancienne ?
– Migration : Est ce que les versions des outils sont les mêmes ?
– Droits : Que se passe t’il si mes droits sont réduis ?
– Accès développeur : Puis je continuer à travailler sur le serveur ou faut il prévoir des outils en local ?
– Accès aux sources : Est ce que toutes les données sources de mon système BI sont toujours accessibles avec les mêmes URL ?
– Accès à la restitution : Les utilisateurs pourront ils accéder aux rapports, aux cubes de la même manière ?
– Suivi de la vie des développements : Que faire des vieux développements inutilisés ? Comment les identifier ?

D’une manière plus générale, je pense qu’il faut gérer un changement de datacenter comme un projet à part entière et plus encore lorsque des éléments vont évoluer (version logiciels ou architectures techniques par exemple). La rédaction d’un document décrivant le processus/plan d’action permet d’anticiper les problèmes qui vont être rencontrés, d’anticiper les éventuelles demandes (droits et accès) ou encore de réfléchir aux mécanismes de roll back.

Dans le cas de mon client, nous avons eu l’opportunité d’effectuer sur plusieurs semaines un « parallel run » entre les anciens serveurs et les nouveaux serveurs. Ainsi, nous avons pu réaliser de nombreuses comparaisons :
– Volumes de données identiques,
– Sources accessibles,
– Performances similaires ou mieux.
– …
Ce procédé nous a permit de conclure avec certitude que les vieux serveurs pouvaient être décommissionés sans risque.

Et vous, avez vous rencontré d’autres problématiques lors de vos changements de serveur ? Comment les avez vous résolu ?

A bientôt,

Guillaume

Envoyer des mails avec un relais SMTP / Send Mail using a SMTP Relay

Bonjour,

Une des « lacunes » (nous verrons que c’est une contrainte judicieuse) de SQL Server depuis plusieurs versions est l’impossibilité d’envoyer simplement des mails par un serveur SMTP qui requiert une authentification (login/mdp). Cette lacune est problématique pour l’utilisation des abonnements dans le Report Server ou pour l’utilisation de la tache Send Mail dans SSIS.

La demande d’ajout de la fonctionnalité a été faite sur le site de Microsoft (https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=332979) et pour le moment, 2 actions de contournements sont proposées.

Voici un descriptif de celle qui consiste à mettre en place un Relais SMTP sur le serveur. La mise en place se fait en 2 étapes, installation puis configuration.

Installation

L’installation est assez simple. Elle consiste à ajouter le service SMTP Server à partir du Server Manager.
Automatiquement, l’installation d’autres services et fonctionnalités vous sera proposée.

Install SMTP
Install SMTP

Voici le récapitulatif des éléments juste avant l’installation.

Install SMTP 2
Install SMTP 2

Configuration

Une fois que tout est bien installé. il faut configurer votre serveur SMTP en tant que relais. Dans notre cas, nous allons relayer les mails vers le SMTP Gmail. L’applicatif interne enverra donc un mail sans authentification à notre relais et ce dernier le renverra via le SMTP Gmail à son destinataire.

1. Aller dans Internet Information Services IIS 6.0 Manager dans les outils d’administration

2. Aller dans les propriétés de votre SMTP Virtual Server.

Config SMTP Virtual Server
Config SMTP Virtual Server

3. Dans l’onglet General, Aller dans Advanced puis ajouter le port d’ecoute local (25 par défaut).

Config SMTP Virtual Server Advanced
Config SMTP Virtual Server Advanced

4. Dans l’onglet Access, Aller dans Authentification et choisissez Anonymous access.

Config Authentification
Config Authentification

5. Dans l’onglet Delivery, Aller dans Outbound Security et renseigner vos identifiants gmail valide. Valider TLS encryption.

Config Outbound
Config Outbound

6. Dans Outbound Connections, Paramétrer le port du serveur SMTP distant.

Config Outbound Connections
Config Outbound Connections

7. Dans Advanced, Parametrer le Smart host avec smtp.gmail.com et Renseigner le FQDN de votre machine.

Config Advanced Delivery
Config Advanced Delivery

8. Valider avec OK puis Cliquer sur Domains

9. Ajouter un domaine distant.

10. Accepter que les mails entrant soient relayés vers ce domaine et Forwarder tous les mails vers le smart host.

Config Domain
Config Domain

11. Renseigner de nouveau l’authentification au SMTP Gmail.

Config Domain Outbound Security
Config Domain Outbound Security

12. Valider tout.

Pour tester :

13. Lancer SSIS et ajouter un composant Send Mail.

14. Paramétrer le SMTP a utiliser avec le FQDN.

SMTP Connection Manager Editor SSIS
SMTP Connection Manager Editor SSIS

15. Renseigner le composant Send Mail et Exécuter la tache.

Attention :

Une fois que votre relais est fonctionnel, il est très important d’en limiter l’usage. Pour cela, vous devez paramétrer les Controles de connexion et les Restrictions de relais dans l’onglet Accès.

Cette solution simplifie l’administration en cas de changement du serveur SMTP. En effet, il suffit de modifier le serveur SMTP dans le IIS Manager pour que la modification soit prise en compte pour tous les outils utilisant le relais. Cette obligation d’usage d’un relais pour envoyer des mails authentifiés me parait donc justifiée pour la pérennité du SID.

Sources :

http://www.itsolutionskb.com/2008/11/installing-and-configuring-windows-server-2008-smtp-server/

2005 – Stage de 3 mois chez MAAF Assurances

Bonjour,

Voici le premier billet basé sur une expérience professionnelle passée. Vous trouverez dans cet article le cadre de la mission, une explication du projet puis quelques informations sur sa réalisation.

Dans le cadre du DUT STID (Statistique et Traitement Informatique des Données) à Niort (79), j’ai effectué un stage chez MAAF Assurances (Mutuelle d’Assurance Artisanale de France) du 28 mars au 3 juin 2005. La MAAF est un prestataire de services d’assurances et d’épargnes.

J’ai été accueilli dans le service Informatique Décisionnelle et plus précisément dans l’entité Infrastructure, Expertise et Débugg dirigée par Alain Thurpeau. Le thème de mon stage faisait suite à un besoin exprimé au cours d’atelier de concertation entre les maîtrises d’ouvrage et les chefs de projet de différents services.

Dans le cadre de qualification, un environnement est utilisé par différents outils testés par différents services. Les testeurs utilisent la meme base de données. Les données peuvent etre amenées à etre modifiées soit pour correspondre au test (exemple : on met une valeur aberrante), soit par les programmes. Les données ne sont pas réservés pour les tests de chaque programme et 2 programmes peuvent donc utiliser les mêmes données ce qui est source d’erreurs.

Mon projet a consisté à concevoir une base de données Access afin d’assurer la réservation de liste. En terme de gestion de projet, j’ai réalisé le Cahier des Charges Utilisateurs qui aurait normalement du être rédigée par les MOA. Afin de bien réaliser cette tache, j’ai rencontré les différents acteurs avec un questionnaire et une maquette du futur programme. Ensuite, je me suis appuyé sur des spécifications pour développer le gestionnaire en VBA.

Le gestionnaire a été testé puis présenté officiellement à tous les utilisateurs.

Cette première expérience dans le monde informatique a été très enrichissante. Elle m’a permis d’acquérir des connaissances (Chaîne du décisionnel, Processus de gestion de projet…), des compétences (Développement VBA…) et du savoir-être (Communication, Compréhension d’expression de besoin…)

A bientôt,

Guillaume