Automatisation des versions Open Source

ProblemsOfSumit

Automatisation des versions Open Source


Je recherche un outil / script qui automatiserait les choses que je dois toujours faire lors de la publication d’une nouvelle version de ma bibliothèque open source. Comme:

  • version npm [majeur / mineur / patch]
  • git push –tags
  • npm publier
  • créer une nouvelle version sur github
  • créer une nouvelle demande d’extraction de développer en branche principale
  • fusionner dans la branche principale
  • peut-être exécuter des scripts construits et valider les fichiers construits / dist
  • mettre à jour les versions dans README.md
  • ect (pas dans cet ordre évidemment)

Existe-t-il une solution populaire utilisée par d’autres mainteneurs OSS ou est-ce que tout le monde écrit ses propres scripts?

Si l’écriture de mon propre script est la meilleure solution, qui pourrais-je aborder (langue, etc.)?

Réponses


 Steve Barnes

Les deux clients d’intégration continue Jenkins et Travis vous permettent un flux de travail qui s’exécute comme suit:

  1. Vous vous engagez sur VCS
  2. Un certain intervalle spécifié plus tard, l’outil CI vérifie le VCS et repère la nouvelle version.
  3. Une nouvelle construction est tentée – si elle réussit
  4. Les tests sont exécutés – s’ils réussissent
  5. La nouvelle version est déployée / téléchargée partout.

Vous pouvez même avoir des branches / balises qui sont construites et testées et d’autres qui sont construites, testées et déployées.

Les deux peuvent créer et tester plusieurs cibles.

Les deux sont gratuits, gratuits et open source et bien utilisés dans la communauté open source.

Il existe un grand nombre d’outils CI qui peuvent faire la même chose, certains sont gratuits, d’autres non et certains ne prennent en charge qu’un sous-ensemble limité de plates-formes, mais je pense que les éléments ci-dessus sont deux des plus largement utilisés dans la communauté open source.

En termes de modification de vos informations de version, de nombreux systèmes VCS permettent d’y accéder soit par substitution de variables, soit par script à l’aide de hooks – il s’agit le plus souvent de scripts batch (bash ou bat) ou python.


 CAD97

J’ai trouvé l’outil!

semantic-release

publication de packages entièrement automatisée

Faites-nous confiance, cela changera votre flux de travail pour le mieux.

– egghead.io

Semantic Release est un outil conçu pour effectuer des validations Git, exécuter des tests et publier votre code tout en suivant les bonnes spécifications SemVer pour vos numéros de version.

Une semantic-releasefois la configuration [sic] obtenue, il [génèrera les journaux des modifications et la version de remplacement] après chaque génération d’intégration continue réussie de votre branche principale (ou de toute autre branche que vous spécifiez) et publiera la nouvelle version pour vous. De cette façon, aucun humain n’est directement impliqué dans le processus de publication et vos versions sont garanties non romantiques et non sentimentales.

En plus de la publication npm, par défaut, il prend également en charge la génération de builds vers GitHub.

C’est ce qui se passe en série:

  1. git push Le nouveau code est poussé et déclenche une construction CI.
  2. semantic-release pre Sur la base de toutes les validations qui se sont produites depuis la dernière version, le nouveau numéro de version est écrit dans le package.json.
  3. npm publish La nouvelle version est publiée à npm.
  4. semantic-release post Un journal des modifications est généré et une version (y compris une balise git) sur GitHub est créée.

Remarque: la mise en œuvre actuelle de la version / de la balise est liée à GitHub, mais pourrait être ouverte à Bitbucket, GitLab, et al. N’hésitez pas à envoyer des RP pour ces services.

(Formatage adapté.)

Il prend également en charge les plugins personnalisés , vous pouvez donc écrire ou trouver des plugins pour le faire faire ce que vous voulez.

Ceci est généralement exécuté sur le serveur CI, plutôt que localement. Et comme note finale:

Est-ce vraiment une bonne idée de sortir à chaque push?

C’est en effet une excellente idée car elle vous oblige à suivre les meilleures pratiques. Si vous ne vous sentez pas à l’aise de rendre chaque fonctionnalité de passage ou de corriger votre branche principale adressable via npm, vous pourriez ne pas traiter votre maître correctement. Jetez un œil aux flux de travail des succursales. Si vous pensez toujours que vous devriez avoir le contrôle sur le moment exact de votre publication, par exemple parce que vous suivez un calendrier de publication, vous ne pouvez publier que sur la branche production / déploiement / publication et y pousser votre code à certains intervalles, ou mieux encore utiliser des balises dist.


 CAD97

Étant donné que les pipelines de génération / publication sont très spécifiques aux technologies spécifiques que vous utilisez, l’écriture de votre propre script est probablement la meilleure option. Il vous donne un contrôle total sur ce qui se passe dans votre pipeline.

Tous les principaux langages de script permettent de hisser une commande sur la ligne de commande. Ainsi, il vous suffit de:

  1. Identifiez les étapes exactes requises pour créer, tester et publier votre bibliothèque
  2. Déterminez ce qui doit changer en fonction de la version de la nouvelle version
  3. Configurez le script pour suivre ces étapes que vous avez déterminées en (1) et (2).

Je suggère de passer le nouveau numéro de version. De plus, assurez-vous de tester ce script contre un mannequin en amont pour éviter de polluer votre projet principal.

De nombreux outils d’intégration continue peuvent exécuter des tests sur votre code à chaque validation. Je suggère d’utiliser l’un de ceux-ci pour tester, puis votre script de génération n’a plus qu’à bump la version, la génération et la publication.

EDIT: Je me suis agréablement surpris en trouvant l’outil conçu pour automatiser les npmversions. En tant que tel, voir mon autre réponse. Cette réponse reste un cas général, pour les cas où le pipeline de construction est plus compliqué qu’il ne l’ semantic-releaseest. Je crois toujours qu’un script de génération / publication personnalisé est la meilleure solution générale.


 ProblemsOfSumit

il y a maintenant un outil open source par zeitHQ qui est aussi proche que possible:
https://github.com/zeit/release

 

Automatisation, des, open, source, versions

 

elle.fr

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *