Toutes les entrées suivantes sont vendues. J'ai essayé de le changer en un bon feeling parce que je vais le monter moi-même, mais l'entrée originale était trop bonne et elle est devenue une entrée avec presque le même contenu.
Automatisation du déploiement en équipes avec plusieurs projets
À l'origine, il était automatisé avec un script shell. Ce n'était pas un gros problème, mais j'avais l'impression que quelqu'un qui était doué pour les scripts shell le maintiendrait, donc je voulais que quiconque puisse le réparer plus facilement. La question de savoir lequel utiliser, Capistrano, est que la société actuelle est basée sur Python et qu'il n'y a presque personne qui touche Ruby, j'ai donc choisi Fabric comme méthode d'élimination.
Comme mentionné dans l'entrée d'origine, le problème avec Fabric est qu'il n'a pas de cadre de base, vous devez donc l'écrire à partir de zéro. Nous avons décidé de créer un cadre minimal et de le fournir à l'équipe.
├── README.md
├── lib
│ ├── git.py
│ └── hipchat.py
├── projectA
│ ├── README.md
│ ├── config
│ │ ├── common.py
│ │ ├── develop.py
│ │ ├── production.py
│ │ └── staging.py
│ └── fabfile.py
├── projectB
├── projectC
Créez un répertoire pour chaque projet et gérez les éléments qui peuvent être partagés dans le répertoire lib. La différence avec l'entrée d'origine est que le répertoire commun a été renommé en lib et que le répertoire de configuration absorbe différents paramètres pour chaque environnement. (Je pense que je vais revenir au commun.)
L'interface est unifiée même si les projets sont différents afin d'éliminer la personnalité.
Déploiement normal
fab -H host1,host2 develop deploy
Déployer avec la branche spécifiée
fab -H host1,host2 develop deploy:feat/ABC
retour en arriere
fab -H host1,host2 develop rollback
Le standard load_settings () de Fabric ne pouvait gérer que des chaînes, j'ai donc rendu possible l'utilisation des dictionnaires et des listes comme suit. La quantité de code a légèrement augmenté, mais l'évolutivité a augmenté.
fabfile.py
@task
def develop(user='vagrant'):
"""Environnement de développement"""
config.develop.develop(user)
@task
def staging(user=''):
"""Environnement de mise en scène"""
config.staging.staging(user)
@task
def production(user=''):
"""Environnement de production"""
config.production.production(user)
@task
def deploy():
"""Déployer"""
Écrivez le processus ici
config/develop.py
def develop(user='vagrant'):
"""Environnement de développement"""
env.environment = 'develop'
env.user = user
…
…
Déployez en supposant qu'il échouera - le journal de Hitode909
Je suis vraiment désolé pour le pakuri rond, mais j'aimerais le faire. Je souhaite réduire le nombre d'opérations que je vois dans le manuel.
Je vais vous apprendre la commande rollback
Conseil: pour le récupérer, exécutez la commande suivante
fab -H host1,host2 production rollback
Ne pas afficher de choses inutiles
Je veux que le déployeur sache quoi faire ensuite en regardant le journal à l'écran. Même ceux qui se déploient pour la première fois ne devraient pas hésiter.
fab -l
Commande standard Fabric. Rédigez correctement vos commentaires et laissez les utilisateurs les utiliser en toute confiance.
% fab -l
Available commands:
déployer déployer
développer un environnement de développement
environnement de production de production
rollback rollback
environnement de préparation
C'est correct d'écrire dans Confluence, mais si c'est quelque chose qui est géré par GIT, j'aimerais l'écrire dans README et mettre un lien vers Confluence.
Rédigez un fichier README.md facile à comprendre
Name
====
Overview
## Description
## Demo
## VS.
## Requirement
## Usage
## Install
## Contribution
## Licence
[MIT](https://github.com/tcnksm/tool/blob/master/LICENCE)
## Author
[tcnksm](https://github.com/tcnksm)
Pour les projets internes, écrivez également:
## Document
## Ticket
## Deploy
## Test
En les écrivant, les membres qui ont participé au projet pour la première fois ne se perdront pas. Tout ce que vous avez à faire est de terminer le référentiel, mais les projets historiques peuvent avoir de la documentation dispersée. Il n'y a pas de problème si les membres sont impliqués dans le projet depuis longtemps, mais ce sera un fardeau pour les nouveaux membres. Je veux m'assurer que tout membre peut participer au projet en douceur.
Je voulais aussi utiliser Consul et Capistrano, mais quand j'ai essayé de résoudre le problème actuel en douceur, c'est devenu comme ça. J'ai hâte de voir comment ce mécanisme survivra un an plus tard.
Je pourrais écrire un test, mais je n'ai pas pu prendre autant de temps. Ce qui suit est un lien de référence.
https://github.com/fabric/fabric/tree/master/tests http://www.obeythetestinggoat.com/unit-testing-fabric-deployment-scripts.html
Il existe également les bibliothèques suivantes en standard dans Fabric.
class FabricTest(object):
"""
Nose-oriented test runner which wipes state.env and provides file helpers.
"""