SlideShare LAG #2 - DevOps Center- 27-10-2022.pptx

Agenda
01 Présentation speakers
02 Setup du DevOps Center
03
Cas d’usage simple du DevOps Center
04
Mise en place du Pipeline
Partage documentation et échanges sur limitations
05
Les autres meetings de la communauté
06

Speakers
Arnaud Sourdillon
Salesforce Architect
Salesforce Solution Architect
19 années d'expérience dans l'IT et Transformation Digitale
8 années dans l’écosystème Salesforce
(Architecture, conception et pilotage de mise en oeuvre)
10x certifié Salesforce
Passionné de Guitare, adore l'Escalade et le Trail

Quentin Dalmazir
Salesforce Application Architect
8 années dans l’écosystème Salesforce
(Architecture, conception et developpements)
10x certifié Salesforce
Apprenti pianiste, pratique le tennis et le VTT
Speakers

● Activation et installation du package
● Attribution des droits
● Création d’un environnement GitHub
● Création d’un projet DevOps Center
● Connexion aux environnements Salesforce
● Création du pipeline
Setup DevOps Center

Démonstration
https://drive.google.com/file/d/1vz1S3yu9ERLbDQcwKAoYUPVcL0YUqKxG/view?usp=sharing

Une étape du pipeline doit correspondre à une branche du repo Git et à un environnement
Salesforce sur lequel les changements seront déployés
Il peut y avoir plus de 10 étapes sur le pipeline
Sur des étapes du pipeline il est possible de regrouper les work item en un seul pour éviter de
devoir les pousser un à un (recommandation : activer l’option au niveau stage d’intégration).
Avoir au moins 2 étapes, une pré-prod(intégration) et une prod. Si vous êtes en mode sandbox,
prévoir à minima une 3eme étape
Mise en place du pipeline

Exemple d’un pipeline simple
Mise en place du pipeline

- new : Connexion du Work Item à un environnement de dev
- In progress : Ajout de la métadata au Work Item
- In review : La PR est créé coté GitHub
- Ready to promote : Le work item devient disponible sur le pipeline pour déploiement sur les
environnements suivants
- Promoted : déploiement effectué
- Closed : Work item abandonné
Cycle de vie d’un work item

DevOps Center (Beta) - Documentation
Informations générales sur DevOps Center:
https://www.salesforceben.com/salesforce-devops-center/
Guide d’installation pas à pas :
https://www.asagarwal.com/step-by-step-guide-to-getting-started-with-salesforce-devops-center/
Trailhead DevOps Center Group :
https://trailhead.salesforce.com/fr/trailblazer-
community/groups/0F94S000000Guyg?tab=discussion&sort=LAST_MODIFIED_DATE_DESC
Guide DevOps Center Elements.cloud (intégration Jira) :
https://drive.google.com/file/d/1024U-zG45kIWAeC9zg3HmFKzQMGhKN3a/view?usp=sharing

Limitations actuelles
Sandbox vs scratch orgs

Limitation actuelle
Il est difficile d’ignorer des metadata qui ont été modifiées et que l’on ne souhaite pas déployer
Le lien avec VSCode en local peut être flou notamment dans le cas d’utilisation de scratch orgs.
La branche est synchronisée en locale mais le work item est lié à une branche également, la
modification des deux cotés peut être problématique
Check automatisé sur les PR
Points d’attention :
La mise en place sur un environnement existant peut être compliqué, car l’initialisation du dépot
Git + des différents environnements doit être bien faite pour éviter les blocages lors de
déploiement

Limitations actuelles
DevOps Center est un outil de déploiement conçu pour remplacer les changes set.
Ce n’est pas un remplaçant des solutions de DevOps qui peuvent être en place aujourd’hui chez pas mal de clients
DevOps Center ne contient pas certaines fonctionnalités telles que:
la sauvegarde et le retour en arrière
les tests
la vérification des conflits → À mitiger, Salesforce recommande un ordre dans lequel faire passer les work items + s’il y a des conflits le promote
est bloqué, mais le conflit est à résoudre côté Git
Il s'agit plutôt d'un moyen simple de mettre en place un pipeline de déploiement avec le VCS GitHub.
L'architecture du DevOps Center est en place pour permettre des extensions développées par des partenaires afin de prendre en charge des
cas d'utilisation plus larges.
Limites actuelles
Uniquement GitHub. (BitBucket sur la feuille de route?).
Dev Org-Based pas Package-based Dev
Pas d'intégration Jira
Il n'est pas possible de voir si un élément de métadonnées se trouve dans ≠ Work item. Cela rend difficile l'évaluation du risque de promotion
des éléments de travail. Cela rend difficile la résolution des erreurs Github, par exemple l'erreur de rebasement qui apparaît lorsqu'un work item
ne peut pas être promu parce qu'il a besoin de changements qui se trouvent dans un autre work item → Cas notamment des profils.
Idem avec Change Sets mais on ne le voit pas parce qu'un change sets écrase simplement les métadonnées au lieu de signaler un conflit.
En utilisant DevOps Center, GitHub et le contrôle de la source, vous mettrez en place des pratiques de gestion des metadata plus pérennes.
La bonne nouvelle : Les partenaires peuvent étendre DevOps Center pour résoudre bon nombre de ces limitations.

Les autres meeting de la communauté
Les événements de la communauté
Novembre
French Touch Dreamin
Le 1er décembre à Paris
LYON
Lyon Salesforce Saturdays
1 samedi sur 2
Prochains event ce samedi 29 octobre 2022
Afterwork networking des 3 groupes Lyonnais
Jeudi 24 novembre au Kargo Kulte

Send Us Your Feedback!
Please rate your overall satisfaction
with your recent session:
Very satisfied
Satisfied
Somewhat satisfied
Not very satisfied
Not at all satisfied
Don’t know/Not applicable
À la suite de ce meeting, vous allez
recevoir un email vous demandant
d’évaluer cette session.
Vos retours sont extrêmement
importants, n’hésitez pas à nous laisser
vos commentaires pour améliorer les
prochaines sessions.

SlideShare LAG #2 - DevOps Center- 27-10-2022.pptx

SlideShare LAG #2 - DevOps Center- 27-10-2022.pptx

Recommandé

Recommandé

Contenu connexe

Similaire à SlideShare LAG #2 - DevOps Center- 27-10-2022.pptx

Similaire à SlideShare LAG #2 - DevOps Center- 27-10-2022.pptx (20)

SlideShare LAG #2 - DevOps Center- 27-10-2022.pptx