[PYTHON] Warum wir Fabric als Bereitstellungstool ausgewählt haben

Alle folgenden Einträge sind verkauft. Ich habe versucht, es in ein gutes Gefühl umzuwandeln, weil ich es selbst zusammenstellen werde, aber der ursprüngliche Eintrag war zu gut und es wurde ein Eintrag mit fast demselben Inhalt.

Automatisierung der Bereitstellung in Teams mit mehreren Projekten

Warum ich mich für Stoff entschieden habe

Ursprünglich wurde es mit einem Shell-Skript automatisiert. Es war kein großes Problem, aber ich hatte das Gefühl, dass jemand, der gut mit Shell-Skripten umgehen kann, es beibehalten würde. Deshalb wollte ich es jedem erleichtern, es zu beheben. Die Frage, welche man verwenden soll, Capistrano, ist, dass das aktuelle Unternehmen auf Python basiert und es fast keine Leute gibt, die Ruby berühren. Deshalb habe ich Fabric als Eliminierungsmethode gewählt.

Strategie

Wie im ursprünglichen Eintrag erwähnt, ist das Problem an Fabric, dass es kein Basis-Framework hat, sodass Sie es von Grund auf neu schreiben müssen. Wir haben uns entschlossen, einen minimalen Rahmen zu schaffen und ihn dem Team zur Verfügung zu stellen.

├── README.md
├── lib
│   ├── git.py
│   └── hipchat.py
├── projectA
│   ├── README.md
│   ├── config
│   │   ├── common.py
│   │   ├── develop.py
│   │   ├── production.py
│   │   └── staging.py
│   └── fabfile.py
├── projectB
├── projectC

Erstellen Sie für jedes Projekt ein Verzeichnis und verwalten Sie Dinge, die im lib-Verzeichnis freigegeben werden können. Der Unterschied zum ursprünglichen Eintrag besteht darin, dass das allgemeine Verzeichnis in lib umbenannt wurde und das Konfigurationsverzeichnis für jede Umgebung unterschiedliche Einstellungen übernimmt. (Ich denke, ich werde zum Gemeinsamen zurückkehren.)

Vereinheitlichung der Begriffe

Die Benutzeroberfläche wird vereinheitlicht, auch wenn die Projekte unterschiedlich sind, um die Persönlichkeit zu beseitigen.

Normaler Einsatz

fab -H host1,host2 develop deploy

Bereitstellen mit angegebenem Zweig

fab -H host1,host2 develop deploy:feat/ABC

roll back

fab -H host1,host2 develop rollback

Umgebungsabhängige Dateien

Fabric's Standard load_settings () konnte nur Zeichenfolgen verarbeiten, daher habe ich es möglich gemacht, Wörterbücher und Listen wie folgt zu verwenden. Die Codemenge hat etwas zugenommen, aber die Skalierbarkeit hat zugenommen.

fabfile.py

@task
def develop(user='vagrant'):
    """Entwicklungsumgebung"""
    config.develop.develop(user)

@task
def staging(user=''):
    """Staging-Umgebung"""
    config.staging.staging(user)

@task
def production(user=''):
    """Produktionsumfeld"""
    config.production.production(user)

@task
def deploy():
    """Bereitstellen"""
Schreiben Sie den Prozess hier

config/develop.py

def develop(user='vagrant'):
    """Entwicklungsumgebung"""
    env.environment = 'develop'
    env.user = user
    …
    …

Freundlichkeit

Bereitstellung unter der Annahme, dass das Tagebuch von --hitode909 fehlschlägt

Das runde Pakuri tut mir wirklich leid, aber ich würde das gerne tun. Ich möchte die Anzahl der Operationen reduzieren, die ich im Handbuch sehe.

Keine Panik

Ich werde Ihnen den Rollback-Befehl beibringen

Tipp: Führen Sie den folgenden Befehl aus, um es wiederherzustellen
fab -H host1,host2 production rollback

Verliere dich nicht

Geben Sie keine unnötigen Dinge aus

Ich möchte, dass der Bereitsteller anhand des Protokolls auf dem Bildschirm weiß, was als Nächstes zu tun ist. Auch diejenigen, die zum ersten Mal einsetzen, sollten nicht zögern.

fab -l

Fabric-Standardbefehl. Schreiben Sie Kommentare richtig und lassen Sie Benutzer sie sicher verwenden.

% fab -l
Available commands:

Bereitstellen Bereitstellen
Entwicklungsumgebung entwickeln
Produktion Produktionsumgebung
Rollback Rollback
Staging-Staging-Umgebung

Schreiben Sie eine leicht verständliche README.md

Es ist in Ordnung, in Confluence zu schreiben, aber wenn es etwas ist, das von GIT verwaltet wird, möchte ich es in README schreiben und einen Link zu Confluence setzen.

Schreiben Sie eine leicht verständliche README.md

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)

Schreiben Sie für interne Projekte auch:

## Document

## Ticket

## Deploy

## Test

Wenn Sie diese schreiben, gehen die Mitglieder, die zum ersten Mal an dem Projekt teilgenommen haben, nicht verloren. Alles, was Sie tun müssen, ist das Repository zu vervollständigen, aber bei historischen Projekten kann die Dokumentation verstreut sein. Es ist kein Problem, wenn die Mitglieder schon lange an dem Projekt beteiligt sind, aber es wird eine Belastung für neu beigetretene Mitglieder sein. Ich möchte sicherstellen, dass jedes Mitglied reibungslos am Projekt teilnehmen kann.

Zusammenfassung

Ich wollte auch Consul und Capistrano verwenden, aber als ich versuchte, das aktuelle Problem reibungslos zu lösen, wurde es so. Ich freue mich darauf zu sehen, wie dieser Mechanismus ein Jahr später überlebt.

Bedauern

Ich könnte einen Test schreiben, aber ich könnte nicht so viel Zeit in Anspruch nehmen. Das Folgende ist ein Referenzlink.

https://github.com/fabric/fabric/tree/master/tests http://www.obeythetestinggoat.com/unit-testing-fabric-deployment-scripts.html

Es gibt auch die folgenden Bibliotheken als Standard in Fabric.

class FabricTest(object):
    """
    Nose-oriented test runner which wipes state.env and provides file helpers.
    """

Referenz

Recommended Posts

Warum wir Fabric als Bereitstellungstool ausgewählt haben
Gleichheitsgarantie mit dem Deployment Tool Fabric + Cuisine