tweeeetyのぶろぐ的めも

アウトプットが少なかったダメな自分をアウトプット<br>\(^o^)/

【Mac】Homebrewとは? - からのFormula、keg、Cellar、Tapってなに?

はじめに

Macな環境はHomebrew使いますよね。

自分も長い事使っていますが、
FormulakegCellarTapあたりについて理解がぼやぁ〜としているなーと思ったので理解整理のための自分メモです。

タイトルとは裏腹にHomebrewそのものの説明は少なめです、すみませんすみません...

f:id:tweeeety:20180503231014p:plain

もくじ

  1. Homebrewとは
  2. Homebrew terminology
  3. Homebrewでのパッケージやアプリのインストール方法
    • brew install
    • brew cask install

1. Homebrewとは

Homebrewそのものの説明ではないと言ったものの
前提としてHomebrewについても触れておきます。

Homebrewとは?

wikiからの引用です

Homebrew(ホームブルー)は、macOSオペレーティングシステム上でソフトウェアの導入を単純化するパッケージ管理システムのひとつである。
MacPortsFinkと同様の目的と機能を備えている。LinuxDebianのAPTに似た使用感で急速に利用が広がっている。  
Homebrew (パッケージ管理システム))

Homebrewのinstall

これも簡単に触れる程度に

$ ruby -e "$(curl -fsS http://gist.github.com/raw/323731/install_homebrew.rb)"

home-brewとは?

home-brewを和訳すると自家醸造飲料(ビール、酒)のことらしいです。

参考サイトの例えが非常にわかりやすかったので引用させていただくと

手順(調理法formula)通りにパッケージを ビルド(醸造brew)して保存(/usr/local/cellerに格納)して、 使う(/usr/loca/binにリンク)ってことです。  
HomeBrewの仕組みについてまとめておく

という感じです。

homebrewのパッケージ管理

一部参考サイトを引用させて頂きますが、主に以下の2種類があります

  1. バイナリを取得するもの
    • ビルド済みのものを配布
  2. ソースコードを取得してビルドするもの

homebrewとは何者か。仕組みについて調べてみた

2. Homebrew terminology

ここからが本題です。

terminologyとは用語の事です。
用語とはFomulaとかCellarとかのことですね。

公式サイトにもHomebrew terminologyとして載っています。
f:id:tweeeety:20180503231110p:plain

公式サイトから引用しつつ、
自分なりに説明とたとえを記載してみました。

Homebrew - Formula Cookbook

公式:Term 公式:Description 補足 ビール作りでいうと
Formula The package definition パッケージの説明書や手順書 調理法
Keg The installation prefix of a Formula Formula のインストール先パス タル、熟成用
opt prefix A symlink to the active version of a Keg version違いのkegに対するactiveへのsymlink 使用中のタルの目印
Cellar All Kegs are installed here keg群のインストール先のパス 地下貯蔵室
Tap A Git repository of Formula and/or commands 公式以外のFormulaやコマンドがおいてあるgitリポジトリ 手順書の集まりとするとCookpad的な..!?
Bottle Pre-built Keg used instead of building from source ソースからビルドするタイプのbuildされていないkeg kegができあがったものとすると、こちらは自宅用手作りキッド的な感じ
Cask An extension of homebrew to install macOS native apps macOSのnativeアプリのパッケージ置き場 自家醸造ビールの酒樽置き場
Brew Bundle An extension of homebrew to describe dependencies アプリなどを一括でインストールするやーつ 1ずつの手順書があるとすると、全部まとめたオードブル手順書みたいな感じ

書いてて無理矢理すぎだろ...
と自分でも思いましたが説明下手にはご愛嬌を...w

3. Homebrewでのパッケージやアプリのインストール方法

Homebrewでのパッケージやアプリのインストール方法2つに触れておきます

  • brew公式のもののインストール
  • brew公式以外のもののインストール

brew公式のもののインストール

コマンド例
# パッケージをさがす
$ brew search <パッケージ名>

# インストール
$ brew install <パッケージ名>
参考

brew公式以外のもののインストール

bew tapとは

brew tapは Homebrewに実装されてるコマンドで、
GitHubのレポジトリにある パッケージをそのままインストールするコマンドです。
 
Homebrewの拡張:brewdler, tap, cask

コマンド例
# brew tapコマンドでcaskのリポジトリ登録
$ brew tap caskroom/cask

# お目当てのものをインストール
$ brew cask install google-chrome
参考
補足

以下のように、以前はbrew tap caskroom/caskも必要だったようですが今は必要なくなっています。

$ brew tap caskroom/cask

# caskをインストール?
$ brew install brew-cask

$ brew cask install google-chrome

その他: ①や②をまとめた手順を書いておいてのインストール

一連の操作を記述したbrewfileを作り
brew bundleコマンドでまとめてインストールすることも可能です。

# Homebrew/bundleをインストール
$ brew tap Homebrew/bundle

# Brewfileを作成する
# dumpに頼らず自身で作るのもあり
$ brew bundle dump

# インストール
$ brew bundle
参考

おわり

自分のたとえがイケてないのが気にかかりますが、
整理してまとめるとすっきりしますね! enjoy!\(^o^)/

【GAE】Google Cloud SDKとgcloudとコンポーネント(components)とgoappをおさらい

はじめに

GAE goな環境を利用しています。
最初に環境構築して以来、google-cloud-sdk 周りにはあまり触れていませんでした。

とある事がきっかけで、

  • google-cloud-sdkgcloudgoappってそれぞれなにするやつ?
  • gcloudコンポーネントgoappってどういう関係?

という所を自分の中で整理できていないなーと思ったので、整理をかねた自分用メモです

アジェンダ

  1. Google Cloud SDKとは
  2. gcloudとは
  3. コンポーネント(components)とは
  4. goappコマンドとは

補足

だいたいの説明は公式サイトから引用させて頂いてます。
引用させて頂いたページはrefします。

1. Google Cloud SDKとは

Google Cloud SDKは、
Google Cloud Platformにホスティングされているリソースと
アプリケーションの管理に使用できる一連のツールです。
gcloud、gsutil、bqなどのコマンドライン ツールもその一部です。
 
gcloud コマンドライン ツールは Cloud SDKと一緒にダウンロードされます。
gcloud の詳しい説明はgcloudの概要にあります。
 
Google Cloud SDK ドキュメント

インストール後のディレクトリはgoogle-cloud-sdkという名前になっています。

Cloud SDK のインストール

このブログでは、それぞれが何なのかの説明にとどめます。

cloud SDK のインストール は以下をご参考ください。
* cloud SDK のインストール

2. gcloudとは

gcloudとは

gcloudは Google Cloud Platformへの
主要なコマンドライン インターフェースを提供するツールです。
 
このツールを使用すると、
コマンドラインから、またはスクリプトその他の自動化により、多くの一般的なプラットフォーム タスクを実行することができます。
 
gcloud の概要

gcloudとSDK

gcloudは Google Cloud SDKの一部です。
gcloud を使用するには、その前にシステムにSDKをダウンロードしてインストールし、初期化する必要があります。
 
デフォルトでは、リリースレベルが一般提供とプレビューのgcloudコマンドのみがインストールされます。
その他の機能は、SDKコンポーネントのalphaとbetaに含まれています。
 
これらのコンポーネントを使用すると、
Google Cloud BigtableGoogle Cloud Dataflow など、一般提供リリースレベルより前の Cloud Platform 機能を gcloud で使用できるようになります。
 
gcloud の概要

3. コンポーネント(components)とは

コンポーネントとは

コンポーネントとは SDKの一部で、個別にインストールできます。
コマンドライン ツール(gcloud、bq、gsutil)、
リリースレベルがアルファ版またはベータ版の gcloud コマンド、
SDK のツールによって使用される依存関係を含むパッケージなどがあります。
 
最も一般的なコンポーネントはデフォルトでインストールされます。
 
SDK コンポーネントの管理 > コンポーネントとは

デフォルトのコンポーネント

以下は、SDKをインストールすると
デフォルトでインストールされるコンポーネントです。

ID 名前 説明
gcloud Default gcloud Commands Google Cloud Platform を操作するためのツール。
このコンポーネントと一緒にインストールされるのは、リリースレベルが一般提供かプレビューのコマンドだけです。
その他のリリースレベルのコマンドを使用するには、gcloud alpha コマンドや gcloud beta コマンド コンポーネントを別途インストールする必要があります。
bq BigQuery Command-Line Tool Google BigQuery 内のデータを操作するためのツール。
gsutil Cloud Storage Command-Line Tool Google Cloud Storage に関連するタスクを実行するためのツール。
core Cloud SDK Core Libraries SDK ツールが内部で使用するライブラリ。

コンポーネントはIDという単位で管理されています。

componentsコマンド

componentsは、gcloudコマンドのサブコマンドのように指定して使います

componentsコマンドのhelp

以下のコマンドでhelpを見ることができます。

$ gcoud components --help

実際に叩いてみた例です

$ gcloud components --help

NAME
    gcloud components - list, install, update, or remove Google Cloud SDK
        components

SYNOPSIS
    gcloud components GROUP | COMMAND [GCLOUD_WIDE_FLAG ...]

DESCRIPTION
    The gcloud components command group lets you control which tools are
    installed in the Cloud SDK. It can be used to install, update and remove
    components of the Cloud SDK, ensuring a lean, up-to-date installation.

    gcloud components regularly checks whether updates are available for the
    tools you already have installed, and gives you the opportunity to upgrade
    to the latest version.

    Certain components have dependencies. gcloud components will install any
    dependencies, and during removal, any dependant components will be
    uninstalled automatically.

GCLOUD WIDE FLAGS
    These flags are available to all commands: --account, --configuration,
    --flatten, --format, --help, --log-http, --project, --quiet, --trace-token,
    --user-output-enabled, --verbosity. Run $ gcloud help for details.

GROUPS
    GROUP is one of the following:

     repositories
        Manage additional component repositories for Trusted Tester programs.

COMMANDS
    COMMAND is one of the following:

     install
        Install one or more Cloud SDK components.

     list
        List the status of all Cloud SDK components.

     reinstall
        Reinstall the Cloud SDK with the same components you have now.

     remove
        Remove one or more installed components.

     restore
        Restore the Cloud SDK installation to its previous state.

     update
        Update all of your installed components to the latest version.

EXAMPLES
    To see all available components:

        $ gcloud components list

    To install a component you don't have:

        $ gcloud components install COMPONENT

    To remove a component you no longer need:

        $ gcloud components remove COMPONENT

    To update all components you have to their latest version:

        $ gcloud components update

    To update all installed components to version 1.2.3:

        $ gcloud components update --version 1.2.3
components list

以下のコマンドで、提供されているcomponentsの一覧とインストール状況を見る事ができます。

$ gcoud components --help

実際に叩いてみた例です。

$ gcloud components list

Your current Cloud SDK version is: 198.0.0
The latest available version is: 200.0.0

┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                   Components                                                   │
├──────────────────┬──────────────────────────────────────────────────────┬──────────────────────────┬───────────┤
│      Status      │                         Name                         │            ID            │    Size   │
├──────────────────┼──────────────────────────────────────────────────────┼──────────────────────────┼───────────┤
│ Update Available │ BigQuery Command Line Tool                           │ bq                       │   < 1 MiB │
│ Update Available │ Cloud SDK Core Libraries                             │ core                     │   7.9 MiB │
│ Update Available │ Cloud Storage Command Line Tool                      │ gsutil                   │   3.5 MiB │
│ Not Installed    │ Cloud Bigtable Command Line Tool                     │ cbt                      │   4.6 MiB │
│ Not Installed    │ Cloud Bigtable Emulator                              │ bigtable                 │   3.8 MiB │
│ Not Installed    │ Cloud Datalab Command Line Tool                      │ datalab                  │   < 1 MiB │
│ Not Installed    │ Cloud Datastore Emulator                             │ cloud-datastore-emulator │  17.9 MiB │
│ Not Installed    │ Cloud Datastore Emulator (Legacy)                    │ gcd-emulator             │  38.1 MiB │
│ Not Installed    │ Cloud Pub/Sub Emulator                               │ pubsub-emulator          │  33.4 MiB │
│ Not Installed    │ Emulator Reverse Proxy                               │ emulator-reverse-proxy   │  14.5 MiB │
│ Not Installed    │ Google Container Local Builder                       │ container-builder-local  │   4.3 MiB │
│ Not Installed    │ Google Container Registry's Docker credential helper │ docker-credential-gcr    │   2.5 MiB │
│ Not Installed    │ gcloud app Java Extensions                           │ app-engine-java          │ 118.9 MiB │
│ Not Installed    │ gcloud app PHP Extensions                            │ app-engine-php           │  21.9 MiB │
│ Not Installed    │ gcloud app Python Extensions (Extra Libraries)       │ app-engine-python-extras │  28.5 MiB │
│ Not Installed    │ kubectl                                              │ kubectl                  │  12.2 MiB │
│ Installed        │ App Engine Go Extensions                             │ app-engine-go            │ 151.3 MiB │
│ Installed        │ gcloud Alpha Commands                                │ alpha                    │   < 1 MiB │
│ Installed        │ gcloud Beta Commands                                 │ beta                     │   < 1 MiB │
│ Installed        │ gcloud app Python Extensions                         │ app-engine-python        │   6.1 MiB │
└──────────────────┴──────────────────────────────────────────────────────┴──────────────────────────┴───────────┘
To install or remove components at your current SDK version [198.0.0], run:
  $ gcloud components install COMPONENT_ID
  $ gcloud components remove COMPONENT_ID

To update your SDK installation to the latest version [200.0.0], run:
  $ gcloud components update

アルファ版コンポーネントとベータ版コンポーネント

コンポーネントにはα版とβ版があり、
それぞれ以下のようにインストールすることで利用可能になります。

$ gcloud components install alpha
$ gcloud components install beta

詳しく知りたい場合は、公式サイトが参考になります

4. goappコマンドとは

これまでなんとなく使っていたものの
goappコマンド が何かというのは自分的に結構曖昧なままでした。

goappコマンドについては別途軽く調べてみたのでこちらもご参考ください。
* 【GAE】goappコマンドについて簡単にまとめてみた

goappコマンドとは

goappコマンドの説明です。

Google Cloud SDKの一部である
gcloudでインストールするコンポーネントの1つに含まれるコマンド

どのコンポーネント

goappコマンドは、
前述したcomponentsコマンドでインストールすることで利用可能です。

先ほどのcomponents listでいうところのapp-engine-goです

$ gcloud components list
~ 省略 ~ 

│ Installed        │ App Engine Go Extensions                             │ app-engine-go            │ 151.3 MiB │

~ 省略 ~ 

goappコマンドの使い方例

以下のように利用することで、
ローカルでGAEアプリの起動ができます。

$ goapp serve app.yaml

おわり

これで誰かに聞かれても
Google Cloud SDKとgcloudとコンポーネント(components)とgoappについて説明ができそうです
\(^o^)/

【GAE】goappコマンドについて簡単にまとめてみた

はじめに

GAE goな環境で開発しているときに、

$ goapp serve app.yaml

という感じで使うわけですが、そもそもgoappってなんぞやという事を軽くまとめてみました。

アジェンダ

  1. goappコマンドの簡単な紹介
  2. goappコマンドとは
  3. goappコマンドのinstall
  4. goapp serveコマンドの挙動

1. goappコマンドの簡単な紹介

goappコマンドは、GAE goな環境で開発する際に使うコマンドです。

例えば、以下はローカルでGAEアプリを起動する際の例です

$ goapp serve app.yaml
INFO     2018-05-02 14:45:49,257 devappserver2.py:120] Skipping SDK update check.
INFO     2018-05-02 14:45:49,353 api_server.py:274] Starting API server at: http://localhost:51983
INFO     2018-05-02 14:45:49,360 dispatcher.py:270] Starting module "Hoge" running at: http://localhost:8080
INFO     2018-05-02 14:45:49,365 admin_server.py:152] Starting admin server at: http://localhost:8000
WARNING  2018-05-02 14:45:49,367 devappserver2.py:215] No default module found. Ignoring.
/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/mtime_file_watcher.py:182: UserWarning: There are too many files in your application for changes in all of them to be monitored. You may have to restart the development server to see some changes to your files.
  'There are too many files in your application for '

2. goappコマンドとは

goappコマンドとは、自分なりの言葉で表現すると

Google Cloud SDKの一部である
gcloudでインストールするコンポーネントの1つに含まれるコマンド

です。(文章がわかりずらくてすみません)

gcloud/SDK/コンポーネントあたりについては別に書いてみたのでご参考ください。

【GAE】Google Cloud SDKとgcloudとコンポーネント(components)とgoappをおさらい

以降で、goappについて掘り下げます

GAEとgo

GAE goな環境で開発すると記載しましたが、
GAEはgoを内包しています。

ためしにversionを見てみます。
PCにインストールしたgoとversionが違う事がわかります

# goappのversionと
# 内包されているgoのversionを確認
$ goapp version
go version 1.8.5 (appengine-1.9.68) darwin/amd64

# PCのgoのversionを確認
$ go version
go version go1.6.2 darwin/amd64

goappのコマンド

helpを見てみるとgoそのもののhelpと似ています

goapp help
$ goapp help
Go is a tool for managing Go source code.

Usage:

  goapp command [arguments]

The commands are:

  serve       starts a local development App Engine server
  deploy      deploys your application to App Engine
  build       compile packages and dependencies
  clean       remove object files
  doc         show documentation for package or symbol
  env         print Go environment information
  bug         start a bug report
  fix         run go tool fix on packages
  fmt         run gofmt on package sources
  generate    generate Go files by processing source
  get         download and install packages and dependencies
  install     compile and install packages and dependencies
  list        list packages
  run         compile and run Go program
  test        test packages
  tool        run specified go tool
  version     print Go version
  vet         run go tool vet on packages

Use "goapp help [command]" for more information about a command.

Additional help topics:

  c           calling between Go and C
  buildmode   description of build modes
  filetype    file types
  gopath      GOPATH environment variable
  environment environment variables
  importpath  import path syntax
  packages    description of package lists
  testflag    description of testing flags
  testfunc    description of testing functions

Use "goapp help [topic]" for more information about that topic.
go help
$ go help
Go is a tool for managing Go source code.

Usage:

  go command [arguments]

The commands are:

  build       compile packages and dependencies
  clean       remove object files
  doc         show documentation for package or symbol
  env         print Go environment information
  fix         run go tool fix on packages
  fmt         run gofmt on package sources
  generate    generate Go files by processing source
  get         download and install packages and dependencies
  install     compile and install packages and dependencies
  list        list packages
  run         compile and run Go program
  test        test packages
  tool        run specified go tool
  version     print Go version
  vet         run go tool vet on packages

Use "go help [command]" for more information about a command.

Additional help topics:

  c           calling between Go and C
  buildmode   description of build modes
  filetype    file types
  gopath      GOPATH environment variable
  environment environment variables
  importpath  import path syntax
  packages    description of package lists
  testflag    description of testing flags
  testfunc    description of testing functions

Use "go help [topic]" for more information about that topic.

goのラッパー的な要素に+αして
GAE goな環境で開発する際に便利な
servdeploybugなどを加えたといった感じです。

3. goappコマンドのinstall

goappコマンドは直接インストールするわけではありません。

2. goappコマンドとは に記載しましたが、
gcloudコンポーネント群のうち、app-engine-goというコンポーネントに含まれるコマンドです。

ここではgoappについてのみ記載します。
gcloudについては公式がわかりやすいです
gcloud の概要

# インストールされる場所を確認
$ gcloud info | grep Installation
Installation Root: [/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk]
Installation Properties: [/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/properties]

# gcloud経由でapp-engine-goをインストールする
$ gcloud components install app-engine-go

# 確認すると
# /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine
# というパスに入っている
$ ls -l /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/*goapp*
-rwxr-xr-x+ 1 tweeeety  tweeeety  5109  5  2 22:08 /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/goapp

# パスを追加
$ export PATH=$PATH:/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine

# 実行権限がないので追加
$ chmod +x /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/goapp

# 使えるようになる
$ goapp version
go version 1.8.5 (appengine-1.9.68) darwin/amd64

app-engine-goでインストールされるもの

/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine 配下には
すでにいくつかのリソースが配置されてますが、
gcloud components install app-engine-go によって以下が追加されます。

-rw-r--r--+  1 tweeeety  tweeeety     5949  3 17 16:55 LICENSE.golang
-rw-r--r--+  1 tweeeety  tweeeety    17738  3 17 16:59 RELEASE_NOTES.golang
-rw-r--r--+  1 tweeeety  tweeeety      248  3 17 16:55 VERSION.golang
-rwxr-xr-x+  1 tweeeety  tweeeety  3679424  3 17 17:00 go-app-stager
-rw-r--r--+  1 tweeeety  tweeeety     4798  3 17 16:59 goapp
-rw-r--r--+  1 tweeeety  tweeeety     4798  3 17 16:59 godoc
-rw-r--r--+  1 tweeeety  tweeeety     4798  3 17 16:59 gofmt
drwxr-xr-x+  2 tweeeety  tweeeety       68  3 17 17:01 gopath
drwxr-xr-x+ 14 tweeeety  tweeeety      476  5  2 21:30 goroot-1.6
drwxr-xr-x+ 14 tweeeety  tweeeety      476  5  2 21:30 goroot-1.8
drwxr-xr-x+ 14 tweeeety  tweeeety      476  5  2 21:30 goroot-1.9

まぁ、go関連で納得という感じですね

4. goapp serveコマンドの挙動

goappというかgoapp serveの挙動です。

help

まずはhelpを見てみます。

$ goapp serve --help

usage: serve [serve flags] [application_dir | package | yaml_files...]

Serve launches your application on a local development App Engine server.

The argument to this command should be your application's root directory or a
single package which contains an app.yaml file. If you are using the Modules
feature, then you should pass multiple YAML files to serve, rather than a
directory, to specify which modules to serve. If no arguments are provided,
serve looks in your current directory for an app.yaml file.

The -host flag controls the host name to which application modules should bind
(default localhost).

The -port flag controls the lowest port to which application modules should
bind (default 8080).

The -use_mtime_file_watcher flag causes the development server to use mtime
polling for detecting source code changes, as opposed to inotify watches.

The -admin_port flag controls the port to which the admin server should bind
(default 8000).

The -clear_datastore flag clears the local datastore on startup.

The -debug flag builds the binary with debug information so that gdb or delve
can be used (default false).

This command wraps the dev_appserver.py command provided as part of the
App Engine SDK. For help using that command directly, run:
  ./dev_appserver.py --help

最後に書いてありますが、dev_appserver.py のラッパーであることがわかります。
また、オプションでportなどが指定できます。

goapp コマンドの中身

中身はpythonで書かれています。
100行ちょいなので読めるレベルです。

#!/usr/bin/env python2.7                                                                                                                                                                                                                                     
#
# Copyright 2011 Google Inc. All rights reserved.
# Use of this source code is governed by the Apache 2.0
# license that can be found in the LICENSE file.

"""Convenience wrapper for starting a Go tool in the App Engine SDK."""
from __future__ import print_function

import argparse
import os
import sys 

SDK_BASE = os.path.abspath(os.path.dirname(os.path.realpath(__file__)))


def FixGooglePath():
  """Adds the python libraries vendored with the SDK to sys.path.

  This allows us to run gotool.py directly and import the dependencies under the
  google/ directory.
  """
  # pylint: disable=g-import-not-at-top
  import wrapper_util
  # pylint: enable=g-import-not-at-top
  sys.path = wrapper_util.Paths(SDK_BASE).v1_extra_paths + sys.path
  if 'google' in sys.modules:
    google_path = os.path.join(os.path.dirname(__file__), 'google')
    google_module = sys.modules['google']
    google_module.__path__.append(google_path)
    if not hasattr(google_module, '__file__') or not google_module.__file__:
      google_module.__file__ = os.path.join(google_path, '__init__.py')


FixGooglePath()


# pylint: disable=g-import-not-at-top
from google.appengine.api import appinfo_includes
from google.appengine.tools.devappserver2.go import goroots
# pylint: enable=g-import-not-at-top


def GetArgsAndArgv():
  """Parses command-line arguments and strips out flags the control this file.

  Returns:
    Tuple of (flags, rem) where "flags" is a map of key,value flags pairs
    and "rem" is a list that strips the used flags and acts as a new
    replacement for sys.argv.
  """
  parser = argparse.ArgumentParser(add_help=False)
  parser.add_argument(
      '--dev_appserver', default=os.path.join(SDK_BASE, 'dev_appserver.py'))
  parser.add_argument(
      '--print-command', dest='print_command', default=False,
      action='store_true')
  namespace, rest = parser.parse_known_args()
  flags = vars(namespace)
  rem = [sys.argv[0]]
  rem.extend(rest)
  return flags, rem


def GetAppYamlPaths(gopath, app_path):
  """Generate possible paths to app.yaml.

  Args:
    gopath: String path to gopath directory.
    app_path: String path to the app.

  Yields:
    Possible paths for app.yaml from app_path up to the gopath root.
  """
  gopath = os.path.abspath(gopath)
  app_path = os.path.abspath(app_path)
  # If we were given an app.yaml, return only it
  if app_path.endswith('.yaml'):
    yield app_path
    raise StopIteration()
  # Always include the app_path, even if not on gopath
  yield os.path.join(app_path, 'app.yaml')
  # But only walk up if we're still on the gopath
  while app_path.startswith(gopath) and app_path != gopath:
    app_path = os.path.abspath(os.path.join(app_path, '..'))
    yield os.path.join(app_path, 'app.yaml')


def _ParseAppYaml(file_name):
  with open(file_name, 'r') as f:
    return appinfo_includes.Parse(f)


def GetGoRoot(gopath, argv):
  """Find the goroot.

  Args:
    gopath: String path to gopath directory.
    argv: A list of strings that looks like sys.argv. The last element of this
      list is checked to see if it's a valid path and, if so, is included in the
      search.

  Returns:
    The path to the correct goroot for the project.
  """
  # First, look for an app.yaml starting in the pwd
  paths = [os.path.realpath(os.path.curdir)]
  # Check if the last cli arg was a path, and look there as well
  if len(argv) > 2:
    app_path = argv[-1]
    if not app_path.startswith('-'):
      app_path = app_path.rstrip('...')
      paths += [os.path.realpath(app_path)]
  for path in paths:
    for app_yaml_path in GetAppYamlPaths(gopath, path):
      if os.path.exists(app_yaml_path):
        app_yaml = _ParseAppYaml(app_yaml_path) 
        if hasattr(app_yaml, 'api_version'):
          return os.path.join(SDK_BASE, goroots.GOROOTS[app_yaml.api_version])

  # Default to the goroot for go1
  return os.path.join(SDK_BASE, goroots.GOROOTS['go1'])


if __name__ == '__main__':
  vals, new_argv = GetArgsAndArgv()
  tool = os.path.basename(__file__)

  # Set a GOPATH if one is not set.
  if not os.environ.get('GOPATH'):
    os.environ['GOPATH'] = os.path.join(SDK_BASE, 'gopath')
  os.environ['APPENGINE_DEV_APPSERVER'] = vals['dev_appserver']

  # Find the correct goroot for the app and make sure we're running the given
  # tool from there.
  goroot = GetGoRoot(os.environ['GOPATH'], sys.argv)
  os.environ['GOROOT'] = goroot
  tool = os.path.join(goroot, 'bin', tool)

  # Remove env variables that may be incompatible with the SDK.
  for e in ('GOARCH', 'GOBIN', 'GOOS'):
    os.environ.pop(e, None)

  # Replace the path to this file with the path to the underlying tool
  new_argv[0] = tool
  if vals['print_command']:
    print(' '.join(new_argv))
  else:
    os.execve(tool, new_argv, os.environ)               

if __name__ == '__main__':がメインです。

tool, new_argv, os.environらを組み立てて
最後のos.execveで実行しています。

os.execveは、現在のプロセスを置き換える形で新たなプログラムを実行します。
os.execve(path, args, env)

os.execveの前に登場する各変数をdumpしてみるとこんな値が入ってます

tool

/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/goroot-1.8/bin/goapp

vals

{'dev_appserver': '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/dev_appserver.py','print_command': False}

new_argv
['/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/goapp',
 'serve',
 'app.yaml']
os.environ
{
 'DIRENV_DIR': '-/Users/tweeeety/gitrepos/Hoge',
 'GOPATH': '/Users/tweeeety/gitrepos/Hoge',
 'PERL_CPANM_OPT': '--mirror http://cpan.metacpan.org',
 'APPENGINE_DEV_APPSERVER': '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/dev_appserver.py',
 'GOROOT': '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/goroot-1.8',
 'DIRENV_DIFF': 'hogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehoge',
 'TERM_PROGRAM_VERSION': '326',
 'SHELL': '/bin/bash',
 'LOGNAME': 'tweeeety',
 'USER': 'tweeeety',
 'HOME': '/Users/tweeeety',
 'PATH': '/usr/local/opt/imagemagick@6/bin:/Users/tweeeety/.plenv/shims:/Users/tweeeety/.plenv/bin:/Users/tweeeety/.nodebrew/current/bin:/Users/tweeeety/.mysqlenv/mysqls/5.1.69/bin:/Users/tweeeety/.mysqlenv/bin:/Users/tweeeety/.mysqlenv/shims:/Users/tweeeety/.mysqlenv/mysql-build/bin:/usr/local/sbin:/Users/tweeeety/.mysqlenv/bin:/Users/tweeeety/.mysqlenv/shims:/Users/tweeeety/.mysqlenv/mysql-build/bin:/usr/local/heroku/bin:/Users/tweeeety/.chefdk/gem/ruby/2.1.0/bin:/opt/chefdk/bin:/Users/tweeeety/.rbenv/shims:/Users/tweeeety/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/go/bin:/sbin:/usr/sbin:/Users/tweeeety/local/bin:/usr/local/opt/go/libexec/bin:/Users/tweeeety/.go/bin:/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine',
 'PS1': '[\\[\\033[40;1;32m\\]\\w \\[\\033[40;2;37m\\]\\t\\[\\033[0m\\]]$ ',
 'TERM_PROGRAM': 'Apple_Terminal',
 'LANG': 'ja_JP.UTF-8',
 'TERM': 'xterm-256color',
 'Apple_PubSub_Socket_Render': '/tmp/launch-95EcNN/Render',
 'SHLVL': '1',
 'TEST_MYSQL_SOCK': '/tmp/mysql.sock',
 'SECURITYSESSIONID': 'hoge',
 'RBENV_SHELL': 'bash',
 'EDITOR': 'vim',
 'TERM_SESSION_ID': 'hogehogehogehoge',
 'SSH_AUTH_SOCK': '/tmp/launch-Z5iV4t/Listeners',
 'MODULE': 'Hoge',
 'TEST_LOCAL_MYSQL_SOCK': '/tmp/mysql.sock',
 '_': '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/goapp',
 'TMPDIR': '/var/folders/5x/2wrjp7td5bj9cprs4c4cwxswqmbl26/T/',
 'PERL5LIB': '/Users/tweeeety/testApp/Sample/lib/:',
 'PLENV_SHELL': 'bash',
 'OLDPWD': '/Users/tweeeety/gitrepos/Fuga',
 '__CF_USER_TEXT_ENCODING': '0x2F45CC46:1:14',
 'PWD': '/Users/tweeeety/gitrepos/Hoge',
 'DIRENV_WATCHES': 'hogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehogehoge',
 '__CHECKFIX1436934': '1'
}

おわり

なんとなくわかった気になりました\(^o^)/

【CircleCI】CircleCI 2.0からはじめる個人での簡単なCI導入方法 - Build結果をSlack通知

はじめに

仕事でcircleciをなんとなーく使っていますが 使いこなしたくなったので改めて個人でもいろいろ試してみるメモです。

githubとの基本的な連携は以下に記載してますのでご参考ください 【CircleCI】CircleCI 2.0からはじめる個人での簡単なCI導入方法 - githubとの連携まで

アジェンダ

  1. Githubと連携する
  2. Slackへ通知する方法の簡単な説明
  3. SLackへ通知する - Incoming WebHooks
  4. Slackへ通知する - CircleCI

1. Githubと連携する

まず、githubにpush(pull request)して、
build結果をSlack通知する流れをものすごくはしょって説明します。

f:id:tweeeety:20180502182937p:plain

  1. 人が、ローカルにてgithubにpushする(pull request)
  2. githubが、pushをトリガーにCircleCIにbuild requestを送る
  3. CircleCIが、コンテナを立ちあげてyamlファイルに従ってbuildを実行する
  4. CircleCIが、結果をgithubに通知する
  5. CircleCIが、結果をslackに通知する
  6. Slackが、人のPCにNotificationする(そういう設定してればですが)
  7. 人が、通知を受けてgithubを見に行く(と、結果が出てる)

1〜4については、github<->CircleCIの基本的なci設定のため今回の通知そのものとは関係ありません。

という事で、今回は 5. CircleCIが結果をslackに通知 の部分についてになります。

補足

基本的なci設定

冒頭にも記載しましたが、基本的な連携については以下をご参考ください 【CircleCI】CircleCI 2.0からはじめる個人での簡単なCI導入方法 - githubとの連携まで

サンプルリポジトリ

今回は、pushするリポジトリとして以下を用意しました。
https://github.com/tweeeety/go-test-circleci-slack-sample

前準備

また、github<->circleCIでciを回すための基本的な連携は終わっている状態です
f:id:tweeeety:20180502183314p:plain

2. Slackへ通知する方法の簡単な説明

CircleCIからSlackへ通知する方法は以下の2通りあります(201804現在)

  1. Incoming WebHooksを使う
  2. CircleCIアプリを使う

どうやって通知するの?

両者、基本的に通知方法はほとんど変わりません。
基本的には以下のような仕組みです。

  • Slackアプリ設定画面でWeb Webhook URLが発行される
    • このとき通知先チャンネルも指定する
  • CircleCIにWeb Webhook URLを登録する
  • CircleCIがbuild後にWeb Webhook URLに対して通知を送る

どうちがうの?

Slackに通知するという点においては、使ってみた感じほとんど違いはありません。
CircleCIアプリの方が、デフォルトでCircleCIからの通知だよというアイコンやらが設定されているのでめんどくさがり屋さんには良いと思います。

3. SLackへ通知する - Incoming WebHooks

簡単ではありますが、Incoming WebHooks での通知設定を参考程度に載せておきます。

Slack側での設定

https://<チーム名>.slack.com/apps を開きます
f:id:tweeeety:20180502183416p:plain

アプリの検索フォームにWebHooksなどをいれるとIncoming WebHooksが表示されるので選択します。
f:id:tweeeety:20180502183427p:plain

Incoming WebHooks画面にてAdd Configurationを選択します。
f:id:tweeeety:20180502183437p:plain

Incoming WebHooksの設定画面が開くので、
通知するチャンネルを選択してAdd Incoming WebHooks integrationを押します
f:id:tweeeety:20180502183450p:plain

設定画面にて、Webhook URL が発行されます。
これを後で使うのでコピるなり画面を開いておくなりします。
f:id:tweeeety:20180502183501p:plain

そのまま画面下にいってSave Settingで完了です。 f:id:tweeeety:20180502183518p:plain

CircleCI側での設定

project(リポジトリ)のbuildページで設定的なアイコンをクリックして設定画面を開きます。
f:id:tweeeety:20180502183532p:plain

NOTIFICATIONS > Chat Notificationsを開きます f:id:tweeeety:20180502183559p:plain

Slackの枠があるのでWebhook URL
先ほど発行したsitaWebhook URLを入力してSaveします。
f:id:tweeeety:20180502183613p:plain

ためしに&Test Hookを押すと、Slack側にこんな感じで通知されると成功です。
f:id:tweeeety:20180502183625p:plain

pull requestを送ってみる

ローカル

ローカルで適当に修正してpush します

# 適当にブランチ切っておく
$ git checkout -b notify-sample

# 適当に修正してpush
$ vi なにかしら適当に修正
$ git add .
$ git commit -m 'notify sample pull request'
$ git push origin notify-sample
circleci

#2としてbuildが走ります f:id:tweeeety:20180502183909p:plain

slack

buildが終わると通知されます f:id:tweeeety:20180502183918p:plain

4. Slackへ通知する - CircleCI

全体的に基本的な流れはIncoming WebHooksと変わりありませんが、
Slack側のみ説明しておきます。

Slack側での設定

探すアプリをIncoming WebHooksではなくCircleCIで検索します。
f:id:tweeeety:20180502183933p:plain

CircleCIアプリが開くのでInstallを押します f:id:tweeeety:20180502183947p:plain

チャンネルを選択してAddCircleCI Integrationを押します f:id:tweeeety:20180502183959p:plain

Incoming WebHooksと同様に
Webhook URLが発行されるのでSave Integrationを押して設定完了です。

CircleCI側での設定

CircleCI側については、Incoming WebHooksとまったく同じ手順です。

pull requestを送ってみる

これもIncoming WebHooksとまったく同様です。

おわり

SlackもCircleCIもWebから操作できるので楽チンです!
enjoy!\(^o^)/

【slack】GitHubとSlackを連携させる - 新しいgithubアプリでpull req通知を受け取るまで

はじめに

GithubとSlack連携は以前から使ってましたが
slackと連携するgithubの新しいアプリが出たらしいので使ってみた感じをメモ

2018/04現在、以前のgithub連携アプリは
Github Notifications (レガシー)
と呼ばれるようです

アジェンダ

  1. 連携させる
  2. 設定を変える
  3. /githubコマンドの使い方

1. 連携させる

https://slack.github.com/ にて連携設定を行います。
連携はwebのみで行えます。

webを開く

https://slack.github.com/ を開いてAdd to Slackを押します
f:id:tweeeety:20180425222358p:plain

アクセス権限を確認

アクセス権限を確認し「Continue」を押します
f:id:tweeeety:20180425222411p:plain

チャンネル選択

アプリがアクセスできるチャンネルを選択します。
とりあえずAll Public Channelsを選択しInstallを押して先に進みます。

2. 設定を変えるにて後述しますが、設定は後で変更できます。
f:id:tweeeety:20180425222423p:plain

Installと連携を確認

Installされるとアプリを開くダイアログが表示されます
f:id:tweeeety:20180425222619p:plain

Slack.appを開くとこんな画面で出迎えてくれます
f:id:tweeeety:20180425222723p:plain

2. 設定を変える

設定を変えるには以下から行います。
https://<チーム名>.slack.com/apps/manage

設定するアプリを探す

https://<チーム名>.slack.com/apps/manageを知らなくてもアプリからも開けます。

  • slackアプリのメニューからCustomize Slackを開きます f:id:tweeeety:20180425222741p:plain

  • Configure Appsを開きます f:id:tweeeety:20180425222806p:plain

  • InstallしたGitHubがあるので選択します f:id:tweeeety:20180425222820p:plain

設定を変える

Settingsを選択します f:id:tweeeety:20180425222841p:plain

Install時の設定でAll public channelsを選択してしまったとしてもこの画面で変更できます。
本来は極力権限はしぼるべきでしょう。
f:id:tweeeety:20180425223155p:plain

補足

特定のChannelのみにした場合でも、
あとからslack側の追加したいchannelで
/invite @github と発言することで後から追加できます

3. /githubコマンドの使い方

使うコマンド

slackのコメント欄にて以下のコマンドを発言することでリポジトリの設定が行えます

コマンド 意味
/github subscribe owner/repo 指定したリポジトリの通知を受け取ります
/github unsubscribe owner/repo 指定したリポジトリの通知をやめます
/github subscribe owner/repo 機能 指定したリポジトリ機能(※1)の通知を受け取ります
/github unsubscribe owner/repo 機能 指定したリポジトリ機能(※1)の通知をやめます
/github subscribe list 通知設定したリポジトリを表示します

※1: 機能には、
↓に記載しているデフォルト通知設定 の機能を個別に指定します。

具体的にはissuespullscommentsなどです。

デフォルト通知設定

  • デフォルトで通知を行う機能
    • issues (イシュー)
    • pulls (プル)
    • statuses (ステータス)
    • コミット
    • deployments (デプロイメント)
    • public (パブリック)
  • デフォルトで通知されない機能
    • reviews (レビュー)
    • comments (コメント)
    • branches (ブランチ)
    • commits:all (すべてにコミット)

特定のリポジトリのsubscribe

ためしにこのリポジトリをsubscribeしてみます
https://github.com/tweeeety/github-slack-new_app

slack上でsubscribeするリポジトリを指定

/github subscribe tweeeety/github-slack-new_app と打ちます

f:id:tweeeety:20180425223256p:plain

Githubアカウントと連携する

SLack上にConnect GitHub accountというボタンが現れるのでおします f:id:tweeeety:20180425223305p:plain

Github上で連携する

Authorize githubを押します
f:id:tweeeety:20180425223321p:plain

押すとSlack上にはSuccess!と通知がきます f:id:tweeeety:20180425223346p:plain

Github上でリポジトリ設定をする

続けてGithub側で
この連携がアカウントの全てのリポジトリを対象とするか、特定のリポジトリとするかを選択します f:id:tweeeety:20180425223413p:plain

完了するとSubscribed to...という通知がきます f:id:tweeeety:20180425223425p:plain

pull requestを送ったsubscribeを確認

https://github.com/tweeeety/github-slack-new_app/pull/1
ためしにこのpull requestを送ってみた結果です。
f:id:tweeeety:20180425223447p:plain

特定のリポジトリの機能のsubscribeをする/やめる

すでに出てきましたが、以下のようなコマンドで機能に対してのsubscribeをする/やめるができます

  • issue(プルリク)に対してsubscribeする
  • issue(プルリク)に対してsubscribeやめる

補足

2018/04現在、EnterpriseSlack Enterpriseには対応してないようです。

以下の公式リポジトリのREADMEに記載があります

This app officially supports GitHub.com and Slack.com but the team plans to support GitHub Enterprise and Slack Enterprise Grid in the future.

おわり

chatOps的にslackから設定ができるのはとっても便利ですね\(^o^)/

docやブログに書くコマンド例の構文や表記の規則

はじめに

docやブログやwikiを書くとき、
こんな感じでコマンド例を載せることは多いと思います。

hoge {fuga|piyo} [-f <filename>]
※ 適当です

そんなとき、
毎回{}[]<>辺りを迷うので、これはちゃんと自分の中でまとめられてないからだな、と。
そんな自分のためのメモです。

規則

構文規則 説明
[ ]
大括弧
[ ](大括弧)は、任意のオプションであることを示します。
大括弧で囲まれていないものの指定は必須です。
[-h host_location]
※ なくても良い
{ }
中括弧
{ }(中括弧)は、相互に排他的な一連のオプションを示します。その中のどれか1つを指定する必要があります。 {-i IP_address | -n host_name}
※ どちらか必須
|
垂直バー
|(垂直バー)は、相互に排他的なオプションを区切ります。 {-i IP_address | -n host_name}
※ どちらか必須
...
省略符号
...(省略符号)は、直前のオプションが異なる値で複数回繰り返し指定可能であることを示します。
大括弧の内側でも外側でも使用できます。
[-x files]...
※ -x file1 -x file2 -x file3

[-x file...]
※ -x file1 file2 file3
< >
山かっこ
< >(山かっこ) は変数を示します。この値は必ず指定する必要があります。 -f <file_name>
\
バックスラッシュ
コマンド業の継続を表す記号です hoge fuga \
-a piyo\
-b poko
太字 正確に入力する必要があるリテラル情報を示します nids-c config_filename
イタリック イタリック・テキストは変数で、それが表現するものと置換する必要があります file_name
" "
二重引用符
オプションを囲む""(二重引用符)は、1つのオプションとして解釈されることを指定します -L "-p 9495"
' '
二重引用符
オプションを囲む''(単一引用符)は、1つのオプションとして解釈されることを指定します ls 'part 1'

※ 参考サイトから説明はお借りしている部分があります

参考サイト

おわり

コマンドラインのコンテキストによっても若干違いはあると思いますが、だいぶ自分の中でもすっきりした気がします\(^o^)/

【設計】みんなが知っておくべき運用設計のノウハウ を読んだメモ - 6章:移行フェーズ

はじめに

タイトルの通りですが、運用って意外に難しいですよね。

仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか?

  • 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...?
  • ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
  • ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ...   サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば

システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。

読んだ本

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349

もくじ

  1. 移行フェーズ
    • 6.1.移行とは

「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。

読んだ感想

この章では運用設計の範疇ではないが、運用と関わりが深い移行について解説されています。

移行については、情報をあまり見た事がなかったのでこうして本にまとめられているのはありがたいです。

6.1.移行とは

移行について

  • 移行とは
    • 完成したシステムを、利用者が利用できるように新システムに切り替えること
    • 運用設計の範疇ではなくプロジェクト全体の範疇
    • ただし、移行後に運用開始のため運用設計が深く関わる
  • 導入するシステムの種類
    • 新システムの追加
      • 新たな作業や業務が発生する
      • 事前説明やユーザ教育が必要
    • 既存システム更改の場合
      • データを引き継ぐ場合、デグレや移行時間の確保が必要
      • 平行運用期間を設ける場合、最新データの扱いの検討が必要
  • 移行の方法
    • 一括移行
      • 全体のシステム停止が可能な場合や複雑で段階移行の影響が読めない場合に採用
      • 移行コスト、手間、時間は最小
      • コンティジェンシープランの考え方が簡単
      • すべての利用者に影響があるためリスクは高い
    • 段階移行
      • 全体でシステム停止できな場合、データが多く一括移行できない場合に採用
      • 移行中は新旧2つのシステム運用が発生する
      • 移行コスト、手間、時間はやや高い
      • コンティジェンシープランの考え方はやや複雑
      • 移行した利用者へのみ影響があるためリスクはやや少ない
    • 平行運用
      • 現行システムと新システムの互換性が重要な場合に採用
      • 移行コスト、手間、時間は高い
      • コンティジェンシープランの考え方は複雑
      • 新システムに問題があっても、旧システムが利用できるためリスクはほぼない

移行の実施

  • 移行計画書
    • 移行概要
      • 移行期間
      • 移行時の業務制限
      • 他システムへの影響
      • 新業務の開始時期
      • 失敗時の影響
      • 切り戻し方針
    • 移行対象
      • 対象データ
      • 移行先
      • ネットワークの切り替え有無
      • 移行後の設備
      • 移行ツール
    • 移行中の影響
      • 利用者への影響
      • データへの影響
      • 運用への影響
    • 移行テスト
      • リハーサル実施方針
      • リハーサル時期
      • リハーサル体制
      • リハーサルスケジュール
    • 移行スケジュール
      • 移行スケジュール
        • 15分〜30分単位で作成し、タスクの依存関係をはっきりさせる
        • 問題がある場合のコンティジェンシープラン発動判断基準も決める
      • ユーザの利用スケジュール
      • ユーザの教育スケジュール
    • 移行体制
      • 当日の体制
        • 移行継続判断を実施するリーダを決める事が重要
      • 移行前後の運用体制
      • ユーザ教育の体制
      • リハーサルの体制

移行時の注意事項

移行に関するトラブルの影響判断を行うため、各チームのリーダクラスがアサインされている事が望ましい

  • 移行全体の判断を行う
  • 問題管理と進捗管理を行う
  • トラブルの影響判断を行う
  • 状況整理、関係者に定期的に周知を行う
移行がうまくいかないと、プロジェクト全体が失敗した雰囲気になる。  
綺麗なドキュメント、しっかりしたテストがあっても、移行が失敗すると台無しになる場合も。

おわりに

移行計画や移行実施って意外にむずかしく、
どんなにテストをしていても移行を雑にやるとすぐ障害につながったりするので個人的には大事にしているフェーズです。

終わりよければすべて良しとはよく言った物で、
終わりがダメでダメな感じ...という事にならないように気をつけたいものです\(^o^)/

紹介

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349