Discussion :

[bibifoke]

Bonjour,

J'ai pour mission de mettre une place un outil d'intégration continue dans ma société.
Nous sommes 100% Microsoft.

J'ai un Repository GIT commun dans lequel des PUSH sont effectués apparemment sans problème.
J'ai installé Jenkins depuis lequel je Build ( avec MsBuild ) les sources de l’entrepôt qui fonctionne également.

Je souhaite maintenant faire de l'intégration continue après le build jenkins, dans IIS ; Localement dans un premier temps.
Quelle est donc la démarche à suivre ?

j'ai essayé de suivre cette démarche qui consiste à construire un projet Visual Studio avec MsBuild et ajouter dans IIS (mon local) mais sans succès :
http://blog.netapsys.fr/deployer-un-...n-job-jenkins/

Est-ce ma commande qui est erronée ? Je n'ai pas de port de configuré; est-ce important pour le déploiement si le site existe deja dans IIS ?
/t:clean /t:rebuild /p:Configuration=Debug /peployOnBuild=True /peployTarget=MsDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:CreatePackageOnPublish=True /peployIisAppPath="NOMDEMASOLUTION" /p:MsDeployServiceUrl=localhost

Voici l’erreur en détail

Lancé par une alarme périodique
Building in workspace C:\Program Files (x86)\Jenkins\jobs\MASOLUTION\workspace
> git.exe rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git.exe config remote.origin.url C:\Repository\MASOLUTION # timeout=10
Fetching upstream changes from C:\Repository\MASOLUTION
> git.exe --version # timeout=10
> git.exe -c core.askpass=true fetch --tags --progress C:\Repository\MASOLUTION +refs/heads/*:refs/remotes/origin/*
> git.exe rev-parse "refs/remotes/origin/master^{commit}" # timeout=10
> git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10
Checking out Revision 096d5b8109ae31b6feb730d5e27a32db2bd398b8 (refs/remotes/origin/master)
> git.exe config core.sparsecheckout # timeout=10
> git.exe checkout -f 096d5b8109ae31b6feb730d5e27a32db2bd398b8
> git.exe rev-list 096d5b8109ae31b6feb730d5e27a32db2bd398b8 # timeout=10
Path To MSBuild.exe: C:\Windows\Microsoft.NET\Framework\v2.0.50727
Executing the command cmd.exe /C " C:\Windows\Microsoft.NET\Framework\v2.0.50727 /t:clean /t:rebuild /p:Configuration=Debug /peployOnBuild=True /peployTarget=MsDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:CreatePackageOnPublish=True /peployIisAppPath=SAGHAI /p:MsDeployServiceUrl=localhost SAGHAI.SLN " && exit %%ERRORLEVEL%% from C:\Program Files (x86)\Jenkins\jobs\RMFLICLI\workspace
[workspace] $ cmd.exe /C " C:\Windows\Microsoft.NET\Framework\v2.0.50727 /t:clean /t:rebuild /p:Configuration=Debug /peployOnBuild=True /peployTarget=MsDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:CreatePackageOnPublish=True /peployIisAppPath=MASOLUTION /p:MsDeployServiceUrl=localhost MASOLUTION.SLN " && exit %%ERRORLEVEL%%
'C:\Windows\Microsoft.NET\Framework\v2.0.50727' n'est pas reconnu en tant que commande interne
ou externe, un programme ex‚cutable ou un fichier de commandes.
Build step 'Construire un projet Visual Studio avec MSBuild' marked build as failure
Finished: FAILURE

Dernière chose, après le build des sources sur le Repo , quelle est la bonne pratique, est -ce de copier les sources compilées sur un autre répertoire pour ensuite les intégrer ?



Merci par avance pour votre aide

[jonthevice]

Bonjour,

je ne sais pas si tu as déjà trouvé des réponses vu que la question date un peu mais bon je me lance, ça peut toujours aider...

déjà je pense que ton problème venait du chemin vers MsBuild.exe cf les logs : xecuting the command cmd.exe /C " C:\Windows\Microsoft.NET\Framework\v2.0.50727 /t:clean /t:rebuild /...
il manque MsBuild.exe dans le chemin...

ensuite

alors déjà as-tu essayé de publier depuis ton poste de dev (Pour ça tu peux regarder la seconde étape directement et tester de publier depuis VS sur ton IIS local) ?

Sinon de manière générale :

La première étape consiste à installer et configurer webDeploy sur le serveur cible (celui qui héberge les sites). Pour cela suivre les indications à l’adresse : http://www.iis.net/learn/install/ins...ing-web-deploy

Configurer ensuite le serveur IIS pour accepter les connections distantes : sélectionner le serveur, aller dans management service et cocher « enable remote connections »

Enfin aller dans la gestion des programmes, sélectionner WebDeploy, click sur « Change » puis sélections de toutes les fonctionnalités et install.

Notre serveur est prêt à recevoir des déploiements distants.



La seconde étape consiste à configurer les projets à déployer.
Pour cela dans Visual Studio, faire un click droit sur le projet que l’on veut déployer puis « Publish ».
Dans le premier onglet chosir un nouveau profil, par exemple DeployIntegration

Dans l’onglet connexion choisir la méthode WebDeploy et renseigner les infos du serveur dans l'ordre et de tête c'est IP, Apppool et site web. Renseigner aussi le login et password d’accès au serveur (pour tester).


Dans l’onglet settings renseigner la configuration. En général on veut déployer en mode Release – Any CPU et que tous les fichiers existant dans le dossier cible soient supprimés avant le déploiement. Enfin la dernière partie reprend les configuration de connections aux sources de données du web.config et permet, au déploiement, d’écraser ces propriétés avec les valeurs saisies (ça évite de le faire à la main).

Notre profil de publication est prêt. On peut fermer la fenêtre et l’enregistrer ou mieux la tester en cliquant sur "Publish".

Maintenant dans notre projet on a un nouveau profil de publication qui vient d'être créé et qui devra être archivé pour permettre de piloter ça depuis le serveur de build.

La dernière étape concerne le serveur de build (j'utilise TFS pour ma part mais ça n'a pas d'importance pour ce point). Deux cas se présentent.

Le premier cas, le plus simple est celui où nous possédons une solution dont tous les projets de type web doivent être publiés. Il faut dans ce cas créer un profil de publication pour chacun de ces projets déployables.
Attention : mettre le même nom de profil (DeployIntegration dans mon exemple)

Puis éditer la définition de build utilisée pour le déploiement, aller dans l’onglet « Process », dans « Advanced » => « MSBuildArguments » saisir :
/peployOnBuild=True;PublishProfile=DeployIntegration /p:AllowUntrustedCertificate=True /password="LeMotDePasseCorrespondantAuLoginRenseignéDansLesProfils"

Ces paramètres disent à MSBuild que lors de la construction de la solution sélectionnée il devra ensuite effectuer le déploiements des projets web en s’appuyant sur le profil « DeployIntegration ». On est obligé de resaisir le mot de passe de connection au serveur car celui-ci n’est jamais conservé dans le fichier de profil mais stocké en local sur la machine de dev pour des raisons de sécurité.

Sauver la définition de build et lancer la build.

Enfin pour répondre à ta dernière question, en général ce que je fais c'est que j'ai une définition de build/un job pour jenkins, dédié au déploiement qui va faire le travail décrit ci-dessus. En plus de cela, je vais brancher un repository privé qui dépendra du projet (si c'est un petit projet au sens petite équipe et pas de partage des librairies, pas de gestion de droits, unseul feed...) je prends un nuget privé sur lequel je vais pousser mes artefacts pour bien garder mes différentes release.
Si je sais que j'ai des choses plus compliqué (pluseurs projets, des librairies communes, gestion des droits, multi-feed, gestion des licenses,...) alors j'essaie de convaincre de la nécessité d'investir dans une instance artifactory pro.

Bon j'espère que ça servira à quelqu'un