Une meilleur collaboration, les phases
en Devops
Product owner
Développement
Source control Build automatique
Test automatique
Déploiement automatique
Support et exploitation
Comité du projet
Product owner,
Chef de projet,
Architecte
Les tarifs de VSTS
VSTS standard
5 premiers utilisateurs : Gratuit
Utilisateurs 6 à 10 : 5,0598 € chacun
Utilisateurs 11 à 100 : 6,7464 € chacun
Utilisateurs 101 à 1000 : 3,3732 € chacun
1001 utilisateurs et plus : 1,6866 € chacun
Options supplémentaires
Test Manager : 43,85 €/utilisateur
Gestion des packages :
5 premiers utilisateurs : Gratuit
Utilisateurs 6 à 100 : 3,3732 € chacun
Utilisateurs 101 à 1000 : 1,265 € chacun
1001 utilisateurs et plus : 0,4217 € chacun
Build & Release :
Gratuit 1 pipeline, limité à 240 minutes
33,73 €/pipeline
Cloud load testing
20000 premières minutes d’utilisateur virtuel : Gratuit
0,0003 €/minute d’utilisateur virtuel pour 20 001 à 2 M minutes d’utilisateur virtuel
Projet de VSTS – Type de serveur source
Pour créer un projet sous VSTS, il faut définir le serveur source
Git (Version distribué)
Chaque développeur a son repository local et il synchronise son code
avec un serveur distant
Fonctionne en mode déconnecté
La gestion des branches est plus simplifiée et le changement de branche
est plus rapide
TFVC (Version centralisé)
Toute l’équipe partage la même de source sur le serveur
Historique est maintenu sur le serveur
Les branches représentent des répertoires fichiers distant et le
changement est plus long
Architecture Git
• 1 Repository pour le
code qui contiendra 1
branche par feature
• 1 repository
documentation qui
contiendra les sources
du wiki interne, des
docs partagés et des
articles
communautaires
• 1 Repository sql qui
contiendra les fichiers
sql et les données
d’initialisation. 1
feature branche par
base
Repository Code
Ce repository est intégré dans Visual Studio, je n'aborderai pas git par ligne de commande ou
par SourceTree.
Comme je l'ai dis plus tôt, on utilisera une branche par feature et la branche master
contiendra les versions livrées
Depuis le site Internet, vous pouvez récupérer les Howto Rubrique VSTS
http://michelbruchet.azurewebsites.net
Les demandes de révision
Comme nous l’avons vu, GIT utilise des branches pour
séparer le code, les versions et les modifications, nous avons
la branche « Master » pour le delivery et les branches
features pour les features
Un pull request ou demande de révision, permet d’améliorer
la collaboration dans une équipe et d’isoler le travail tant que
le code n’a pas été revue et appréciée par plusieurs
personnes ou par l’équipe en son entier. En effet la branche
master ne sera mise à jour que si toute l’équipe est d’accord
avec le nouveau code
Dans cette image la branche Bleu ne sera mise à jour avec les
modifications de la branche Violette qu’après révision par
l’équipe du code
Depuis le site Internet, vous pouvez récupérer les Howto Rubrique VSTS
http://michelbruchet.azurewebsites.net
Les branches binaires ou de
documentation
Beaucoup de personne, disent que Git n’est pas fait pour stocker du binaire, mais moi je
dis qu’on peut travailler avec Git pour la documentation et on y gagne
• Git nous garantit l’archivage des documentations
• Git nous permet de travailler à plusieurs sur le même document
• Git nous assure le suivi des modifications en temps des documents et le merging
comme avec tout fichier text
• Git nous permet également de mettre en place le processus de révision pour les
documents
Word Pandoc Markdow
.md
Git
Markdow
.md
PandocWord
Depuis le site Internet, vous pouvez récupérer les Howto Rubrique VSTS
http://michelbruchet.azurewebsites.net
Autre vidéo
Merci pour votre assiduité, je vais publié beaucoup d’autre vidéo, technique
(ASP.NET Core / Service Fabric / Powershell / etc..) que de gestion de
projets, architecture d’entreprise
Vous pouvez me contacter par
email : mbruchet@live.fr
Linkedin : https://www.linkedin.com/in/michelbruchet
Facebook : https://www.facebook.com/michel.bruchet.3
Site blog : http://michelbruchet.azurewebsites.net
StartPoint
Logiciel de comptabilité et de gestion