La montée en puissance de GitHub en tant que système de contrôle de version le plus utilisé au monde – et son importance pour les logiciels open source – est un signe clair de l’importance du contrôle de version. En effet, l’intégralité du lecteur CI / CD (intégration continue et livraison continue) ne serait pas possible sans les référentiels de code source qui est la première étape d’un pipeline CI / CD. Au-delà de CI / CD, la fourniture de logiciels modernes devient de plus en plus déclarative, avec des approches telles que GitOps étant le moyen privilégié pour développer non seulement du code mais aussi une infrastructure de conteneurs. Ces approches font partie intégrante de l’automatisation et de l’accélération du cycle de vie de la livraison de logiciels et de le rendre véritablement «continu». Tous ces développements en dehors de Salesforce ont un impact sur la façon dont les applications Salesforce sont créées et développées. Sans surprise, le contrôle de version devient également un élément central de la livraison logicielle Salesforce. Salesforce CI / CD n’est plus une idée nouvelle, mais une idée sur laquelle se fonde chaque organisation qui crée des applications Salesforce. Il existe des solutions CI / CD matures spécialement conçues pour Salesforce. À mesure que les équipes Salesforce adoptent les principes DevOps pour créer et soumettre des applications, elles considèrent le contrôle de version comme un outil clé. Dans cet article, nous examinons ce qu’est le contrôle de version, ses avantages et comment il est mis en œuvre pour fournir Salesforce.
Suttercock
Qu’est-ce que le contrôle de version?
Le contrôle de version vous permet de gérer les modifications apportées aux fichiers au fil du temps. Vous pouvez utiliser le contrôle de version dans le code de version, les binaires et les composants numériques.
– Chuck Gehman, ingénieur marketing, Logiciel Perforce
Le contrôle de version surveille les changements de code, mais surtout, il permet aux développeurs de contourner le code tout en travaillant à distance. Dans la pandémie actuelle, cet accent mis sur le développement à distance est encore plus important.
Traditionnellement, les équipes de livraison de logiciels utilisaient des noms de fichiers uniques pour stocker le code – il s’agit d’un exemple de base de version. Aujourd’hui, il existe des outils puissants qui automatisent tout ce processus de stockage des nouvelles versions et facilitent leur travail.
La version n’est pas seulement pour le code, mais également pour les objets associés tels que les scripts, les documents et les modules complémentaires. Comme le processus de développement logiciel devient de plus en plus complexe, le versionnage est nécessaire pour apporter de la simplicité à un processus autrement complexe.
Les référentiels sont l’épine dorsale du contrôle de version. C’est là que le mot de passe est stocké. Les modifications d’un référentiel distant sont transférées vers un référentiel local, puis les nouvelles modifications sont repoussées d’une machine locale vers un référentiel partagé. Le pouvoir des référentiels est qu’ils peuvent être clonés, branchés, fusionnés et comparés. De cette manière, le contrôle de version permet une collaboration à l’échelle.
Principaux avantages du contrôle de version
Donnez aux développeurs une rétroaction immédiate
Lorsque les développeurs apportent des modifications à un référentiel, le système de contrôle de version vérifie les conflits dans le code. Le système peut corriger automatiquement certains conflits de fusion, mais pour d’autres, le développeur peut voir la liste des conflits et les résoudre rapidement. Ce retour instantané de la qualité du code agit comme une vérification logique du code et réduit les problèmes en aval.
Développer souvent
Les équipes d’ingénierie les plus performantes ont pu atteindre une efficacité supérieure avec un taux de croissance 8x et des temps de croissance 8000x plus rapides.
– Tali Soroker, responsable de contenu, Trop
Le contrôle de version améliore le taux de croissance et la fréquence des versions de plusieurs manières. Premièrement, il permet un développement parallèle où plusieurs développeurs peuvent travailler séparément dans le même référentiel et éventuellement fusionner leurs modifications. Deuxièmement, cela réduit le temps nécessaire pour résoudre les problèmes car il y a moins de changement entre les équipes Dev, QA et Ops. Les problèmes sont détectés tôt et résolus avant qu’ils n’affectent les utilisateurs.
Envoyez des applications fiables
Le contrôle de version comporte plusieurs niveaux de développement pré-code en production. En plus du contrôle initial des litiges, les équipes d’assurance qualité peuvent effectuer une révision du code avant de donner le feu vert au nouveau code. Comme les équipes de développement et d’assurance qualité travaillent ensemble en utilisant la même plate-forme de contrôle de version, cela est cohérent et aide le contrôle qualité à «tourner à gauche» comme prévu dans DevOps
Développeurs en bref
Les développeurs jouent un rôle central tout au long du cycle de vie de la livraison logicielle. À gauche, nous voyons les équipes QA et Ops approcher les équipes de développement et les inclure dans le cadre des tests et de la gestion de la production d’applications. Le contrôle de version, basé sur les référentiels de code source, permet ce virage à gauche aux développeurs. Cela permet aux développeurs d’avoir leur mot à dire sur ce qui se passe en aval dans le code qu’ils écrivent. Il intègre également les processus dans les trois groupes – Dev, QA et Ops. Nous constatons que les développeurs Salesforce deviennent de plus en plus importants dans le processus de livraison de logiciels et le contrôle de version soutient cette tendance.
Contrôle de version axé sur Salesforce
Salesforce possède des fonctionnalités uniques qui nécessitent une version légèrement modifiée du contrôle de version. Outre les référentiels de code source, Salesforce inclut également des sandbox, qui présentent de nombreuses similitudes avec un référentiel mais qui sont toujours différents.
Cadres de sable Salesforce
Un bac à sable dans Salesforce est une copie de l’organisation de production. Il existe différents types de bacs à sable: complet, développeur, développeur pro et certains dossiers de données. Seul l’environnement de test complet contient une copie de toutes les données et métadonnées de l’organisation de production, les autres contiennent toutes les métadonnées et seulement un sous-ensemble des données réelles. Les équipes de livraison de logiciels Salesforce utilisent des sandbox basés sur des métadonnées si nécessaire.
La plupart des entreprises à succès avec lesquelles nous discutons trouvent que chaque développeur doit avoir son propre bac à sable. Ceci est idéal pour contrôler et surveiller le travail. Vous devez également disposer d’un bac à sable d’intégration, de préférence un bac à sable à copie partielle ou complète, qui peut être utilisé pour fusionner le code à mesure que les fonctionnalités sont développées.
– Alex Brausewetter, fondateur, Toile bleue
Ces sandbox existent à côté des référentiels et des conflits peuvent survenir entre les sandbox et les référentiels après chaque engagement. Ensuite, lors du développement des modifications, les équipes peuvent choisir de développer à partir d’un bac à sable ou d’un référentiel. Avec ses fonctionnalités les plus puissantes pour la résolution des conflits et la collaboration, il est préférable de passer d’un référentiel à un bac à sable. Cependant, l’utilisation des deux options est utile.
Il existe généralement de nombreux bacs à sable et référentiels pour chaque groupe et chaque utilisateur. La gestion de tous ces éléments peut augmenter les frais généraux et les rendre contre-productifs. C’est pourquoi les équipes Salesforce DevOps doivent réfléchir à la gestion de leur sandbox et à la gestion de leurs référentiels.
Contrôle de version et gestion du sandbox pour Salesforce
Des solutions telles que AutoRABIT incluent des fonctionnalités qui aident à gérer à la fois le contrôle de version et le bac à sable. Par exemple, AutoRABIT permet la «réservation automatique» des modifications à partir d’un référentiel de code source. Cette automatisation permet non seulement de gagner du temps, mais réduit également le nombre d’erreurs pouvant être glissées lors du déplacement de code.
En termes de gestion du sandbox, AutoRABIT propose une synchronisation sandbox vers différents emplacements. Compare différents bacs à sable et souligne les changements et les petites variations entre eux. En outre, il améliore la gestion du bac à sable avec des journaux et des rapports sur le nombre d’améliorations et d’erreurs, et met en évidence les changements spécifiques qui ont cassé quelque chose. Cela est particulièrement vrai lorsqu’il s’agit de bacs à sable dans de grands organismes, qui peuvent facilement devenir incontrôlables.
Contrôle de version: obligatoire pour les équipes Salesforce DevOps
Le contrôle de version est une partie essentielle du développement logiciel. Cela est particulièrement vrai pour les équipes Salesforce DevOps. Ils ont besoin de la puissance d’un système de contrôle de version et d’une solution de gestion de bac à sable pour fournir des logiciels à l’échelle et à la vitesse exigées par le marché actuel. Cela placerait les développeurs aux commandes et rejoindrait des équipes complémentaires telles que QA et Ops pour tirer pleinement parti de DevOps pour Salesforce. Si vous avez déjà commencé à utiliser les pratiques DevOps pour créer des applications Salesforce, vous avez besoin du contrôle de version et de la gestion du sandbox.
Image suggérée: Pixabay
Affichage des messages:
59
La montée en puissance de GitHub en tant que système de contrôle de version le plus utilisé au monde – et son importance pour les logiciels open source – est un signe clair de l’importance du contrôle de version. En effet, l’intégralité du lecteur CI / CD (intégration continue et livraison continue) ne serait pas possible sans les référentiels de code source qui est la première étape d’un pipeline CI / CD. Au-delà de CI / CD, la fourniture de logiciels modernes devient de plus en plus déclarative, avec des approches telles que GitOps étant le moyen privilégié pour développer non seulement du code mais aussi une infrastructure de conteneurs. Ces approches font partie intégrante de l’automatisation et de l’accélération du cycle de vie de la livraison de logiciels et de le rendre véritablement «continu». Tous ces développements en dehors de Salesforce ont un impact sur la façon dont les applications Salesforce sont créées et développées. Sans surprise, le contrôle de version devient également un élément central de la livraison logicielle Salesforce. Salesforce CI / CD n’est plus une idée nouvelle, mais une idée sur laquelle se fonde chaque organisation qui crée des applications Salesforce. Il existe des solutions CI / CD matures spécialement conçues pour Salesforce. À mesure que les équipes Salesforce adoptent les principes DevOps pour créer et soumettre des applications, elles considèrent le contrôle de version comme un outil clé. Dans cet article, nous examinons ce qu’est le contrôle de version, ses avantages et comment il est mis en œuvre pour fournir Salesforce.
Suttercock
Qu’est-ce que le contrôle de version?
Le contrôle de version vous permet de gérer les modifications apportées aux fichiers au fil du temps. Vous pouvez utiliser le contrôle de version dans le code de version, les binaires et les composants numériques.
– Chuck Gehman, ingénieur marketing, Logiciel Perforce
Le contrôle de version surveille les changements de code, mais surtout, il permet aux développeurs de contourner le code tout en travaillant à distance. Dans la pandémie actuelle, cet accent mis sur le développement à distance est encore plus important.
Traditionnellement, les équipes de livraison de logiciels utilisaient des noms de fichiers uniques pour stocker le code – il s’agit d’un exemple de base de version. Aujourd’hui, il existe des outils puissants qui automatisent tout ce processus de stockage des nouvelles versions et facilitent leur travail.
La version n’est pas seulement pour le code, mais également pour les objets associés tels que les scripts, les documents et les modules complémentaires. Comme le processus de développement logiciel devient de plus en plus complexe, le versionnage est nécessaire pour apporter de la simplicité à un processus autrement complexe.
Les référentiels sont l’épine dorsale du contrôle de version. C’est là que le mot de passe est stocké. Les modifications d’un référentiel distant sont transférées vers un référentiel local, puis les nouvelles modifications sont repoussées d’une machine locale vers un référentiel partagé. Le pouvoir des référentiels est qu’ils peuvent être clonés, branchés, fusionnés et comparés. De cette manière, le contrôle de version permet une collaboration à l’échelle.
Principaux avantages du contrôle de version
Donnez aux développeurs une rétroaction immédiate
Lorsque les développeurs apportent des modifications à un référentiel, le système de contrôle de version vérifie les conflits dans le code. Le système peut corriger automatiquement certains conflits de fusion, mais pour d’autres, le développeur peut voir la liste des conflits et les résoudre rapidement. Ce retour instantané de la qualité du code agit comme une vérification logique du code et réduit les problèmes en aval.
Développer souvent
Les équipes d’ingénierie les plus performantes ont pu atteindre une efficacité supérieure avec un taux de croissance 8x et des temps de croissance 8000x plus rapides.
– Tali Soroker, responsable de contenu, Trop
Le contrôle de version améliore le taux de croissance et la fréquence des versions de plusieurs manières. Premièrement, il permet un développement parallèle où plusieurs développeurs peuvent travailler séparément dans le même référentiel et éventuellement fusionner leurs modifications. Deuxièmement, cela réduit le temps nécessaire pour résoudre les problèmes car il y a moins de changement entre les équipes Dev, QA et Ops. Les problèmes sont détectés tôt et résolus avant qu’ils n’affectent les utilisateurs.
Envoyez des applications fiables
Le contrôle de version comporte plusieurs niveaux de développement pré-code en production. En plus du contrôle initial des litiges, les équipes d’assurance qualité peuvent effectuer une révision du code avant de donner le feu vert au nouveau code. Comme les équipes de développement et d’assurance qualité travaillent ensemble en utilisant la même plate-forme de contrôle de version, cela est cohérent et aide le contrôle qualité à «tourner à gauche» comme prévu dans DevOps
Développeurs en bref
Les développeurs jouent un rôle central tout au long du cycle de vie de la livraison logicielle. À gauche, nous voyons les équipes QA et Ops approcher les équipes de développement et les inclure dans le cadre des tests et de la gestion de la production d’applications. Le contrôle de version, basé sur les référentiels de code source, permet ce virage à gauche aux développeurs. Cela permet aux développeurs d’avoir leur mot à dire sur ce qui se passe en aval dans le code qu’ils écrivent. Il intègre également les processus dans les trois groupes – Dev, QA et Ops. Nous constatons que les développeurs Salesforce deviennent de plus en plus importants dans le processus de livraison de logiciels et le contrôle de version soutient cette tendance.
Contrôle de version axé sur Salesforce
Salesforce possède des fonctionnalités uniques qui nécessitent une version légèrement modifiée du contrôle de version. Outre les référentiels de code source, Salesforce inclut également des sandbox, qui présentent de nombreuses similitudes avec un référentiel mais qui sont toujours différents.
Cadres de sable Salesforce
Un bac à sable dans Salesforce est une copie de l’organisation de production. Il existe différents types de bacs à sable: complet, développeur, développeur pro et certains dossiers de données. Seul l’environnement de test complet contient une copie de toutes les données et métadonnées de l’organisation de production, les autres contiennent toutes les métadonnées et seulement un sous-ensemble des données réelles. Les équipes de livraison de logiciels Salesforce utilisent des sandbox basés sur des métadonnées si nécessaire.
La plupart des entreprises à succès avec lesquelles nous discutons trouvent que chaque développeur doit avoir son propre bac à sable. Ceci est idéal pour contrôler et surveiller le travail. Vous devez également disposer d’un bac à sable d’intégration, de préférence un bac à sable à copie partielle ou complète, qui peut être utilisé pour fusionner le code à mesure que les fonctionnalités sont développées.
– Alex Brausewetter, fondateur, Toile bleue
Ces sandbox existent à côté des référentiels et des conflits peuvent survenir entre les sandbox et les référentiels après chaque engagement. Ensuite, lors du développement des modifications, les équipes peuvent choisir de développer à partir d’un bac à sable ou d’un référentiel. Avec ses fonctionnalités les plus puissantes pour la résolution des conflits et la collaboration, il est préférable de passer d’un référentiel à un bac à sable. Cependant, l’utilisation des deux options est utile.
Il existe généralement de nombreux bacs à sable et référentiels pour chaque groupe et chaque utilisateur. La gestion de tous ces éléments peut augmenter les frais généraux et les rendre contre-productifs. C’est pourquoi les équipes Salesforce DevOps doivent réfléchir à la gestion de leur sandbox et à la gestion de leurs référentiels.
Contrôle de version et gestion du sandbox pour Salesforce
Des solutions telles que AutoRABIT incluent des fonctionnalités qui aident à gérer à la fois le contrôle de version et le bac à sable. Par exemple, AutoRABIT permet la «réservation automatique» des modifications à partir d’un référentiel de code source. Cette automatisation permet non seulement de gagner du temps, mais réduit également le nombre d’erreurs pouvant être glissées lors du déplacement de code.
En termes de gestion du sandbox, AutoRABIT propose une synchronisation sandbox vers différents emplacements. Compare différents bacs à sable et souligne les changements et les petites variations entre eux. En outre, il améliore la gestion du bac à sable avec des journaux et des rapports sur le nombre d’améliorations et d’erreurs, et met en évidence les changements spécifiques qui ont cassé quelque chose. Cela est particulièrement vrai lorsqu’il s’agit de bacs à sable dans de grands organismes, qui peuvent facilement devenir incontrôlables.
Contrôle de version: obligatoire pour les équipes Salesforce DevOps
Le contrôle de version est une partie essentielle du développement logiciel. Cela est particulièrement vrai pour les équipes Salesforce DevOps. Ils ont besoin de la puissance d’un système de contrôle de version et d’une solution de gestion de bac à sable pour fournir des logiciels à l’échelle et à la vitesse exigées par le marché actuel. Cela placerait les développeurs aux commandes et rejoindrait des équipes complémentaires telles que QA et Ops pour tirer pleinement parti de DevOps pour Salesforce. Si vous avez déjà commencé à utiliser les pratiques DevOps pour créer des applications Salesforce, vous avez besoin du contrôle de version et de la gestion du sandbox.
Image suggérée: Pixabay
Affichage des messages:
59
Post Views:
170
