2018-04-12

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

設計運用

はじめに

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

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

必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...？

ローンチしちゃったから走りながら設定変える辛い...いや無理かも..

ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ... 　サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば

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

読んだ本

みんなが知っておくべき運用設計のノウハウ

posted with amazlet at 18.04.11

(2017-10-30)
売り上げランキング: 349

Amazon.co.jpで詳細を見る

読んだ感想

この章では要件定義での機能要件と非機能要件、
非機能要件という位置づけの運用設計という形で説明されています。

個人的には、運用設計としての検討項目が体系的にまとめられているので
今後プロジェクトを進める上でとても参考になるなーと思いました。

「運用で検討する事をまとめといて」みたいなときって慣れてないと何を考えたら良いんだろう...となりますよねw

2.1.要件定義とは

要件定義では、以下のような事を行う

達成しなければならないものや、システムの全体像を明らかにする

必要なサービスを提供するためにどのような実現方法があるかを件とうする

費用や全体スケジュール、実現方法を鑑みながら決める

要件定義の注意点

要件は常に変わる

システムの全体像が見えてくるとあれもこれも欲しい気持ちになる

要件定義段階はできる限りの可能性を検討しておく事が望ましい

顧客とのギャップ

顧客は大枠のシステムの実現性や必要な要件を知りたい

エンジニアはどうやって実現するかになりがち

求められているものは「システム設計」ではなく「検討漏れのない要件定義書」

何かなければ議論は始まらない

顧客は正解をもっていない

要件を理解してこちらから提案する

これはきっと大丈夫だろうは、どこかで出戻りが発生する

「違っている」や「関係ない」も含めて細かく合意していく

特定の製品を指定する場合

刷新するだけでなく「使い慣れている製品」も重要なファクター

運用担当者への引き継ぎ稼働の削減が見込める

現行踏襲に気をつける

現行踏襲のメリ・デメは検討する

メリット

移行がスムーズ

基本設計や運用フローがそのまま使えるので設計コスト削減

すでに全社的に統一されたフローなどは現行踏襲がうまくいく場合が多い

デメリット

新システムとマッチしない

最新機能を導入する機会を失う

負の遺産（やりにくい部分）も引き継いでしまう

現行運用が属人化、高運用スキル者によってギリギリ回っているだけの場合失敗しやすい

2.2.機能要件/非機能要件

書籍では実製品として「洗濯機」を例にあげている

機能要件

洗い

すすぎ

脱水

その他の機能要件

タイマー機能

脱水＋乾燥

非機能要件

何年使えるか

騒音はどれくらい抑えられるか

海外でも使えるか

製品だとわかりやすいが、システムで非機能要件を洗い出すのは難しい

IPAでの非機能要件グレードについて資料的には以下のように定められている

基本的な非機能要件に対する考え方は以下の6点

可用性

必要なときにどれだけ使えるか

性能/拡張性

どこまで性能が発揮できるか、拡張できるか

運用/保守性

運用や保守についての取り決め

移行性

現行データをどのように移行するか

セキュリティ

セキュリティ対策

システム環境/エコロジー

電源設備、耐震免震性

運用設計は非機能要件

あらためて洗濯機の例で表すと

物理的な設計: アプリでいうインフラ設計

設置場所

電源やホースのつなぎ

排水

機能的な設計: アプリでいうアプリ設計

洗い

すすぎ

脱水/乾燥

タイマー

運用設計: アプリでも同じく実際に使う人の動きを設計

洗濯を開始するにはどうするか

乾燥が終わったら取り出す＆たたむにはどうするか

要件定義時に検討しておいたほうが良い運用項目

※ 結構多いけど要件定義時〜基本設計あたりで一緒に検討しないと何度も困った経験がある... ※ それこそローンチ後、あれ？これどうするんだっけ？はここで生まれてる気がしますね

運用体制

現在誰がどのようにシステムを運用していて、今回導入するシステムはどのような体制で運用されるのか

責任分解点を決めるためにも欠かせない

サービスデスクの場所や運用担当者の作業場所、データセンターの運用体制

運用開始後のイメージを作成する

ユーザアカウント管理

ユーザー改廃

アクセス権設定方法

特殊なユーザアカウント

ヒアリング項目例

新入社員時の大量アカウント作成時の対応方法

一次貸し出しなどの特殊アカウントの有無

昇格による権限の付与

人事異動による権限変更

セキュリティ対策

全社のセキュリティポリシーとの照らし合わせ

例

脆弱性対策

ウイルス対策

パスワードルール

セキュリティパッチ適用運用

ジョブ/スクリプト運用

自動化項目

バックアップ/リストア運用

バックアップ

バックアップの概要（RPO）

リストア

リストアのトリガー

申請によるリストアが必要か

申請によるリストアが定常ならその運用設計

監視運用

要件定義フェーズは

「誰が」「どこで」「どのように」「どれくらい」監視するかを決定

「何を」「どれくらいの周期で」「どのレベルまで」監視するかは次工程

ログ管理運用

障害検知用

短くても良い

監査用

長期間保存する必要がある

稼働統計運用

定期報告書の有

システム稼働状況

インシデント件数

顧客がなんのために必要とするかの合意

SLAのため

安定運用の確認のため

ライセンス棚卸しのため

安定運用の確認のため

移行（ユーザ教育含む）

検討する項目

人

データ

ドキュメント

スキル

例

運用メンバーへの運用作業引き継ぎ方法

新システムへのデータ移行

新システムのユーザ説明会の実施

システム切り替え時期と事前周知

BCP/DR

BCP/DRについての運用設計は次工程でも良い。
要件定義の時に検討はする。

BCP

Business continuity plan（事業継続計画）

主眼は事業

災害時に限られた資源でどのように事業を継続していくか

システムが被災しても紙運用で事業が止まらなければ問題ない

DR

Disaster Recovery（災害復旧）

主眼はIT

災害時にどのような体制で、どのようにシステムを復旧するか

システム被災から復旧までの進め方

DR対策

バックアップ
- 最も安価
- 安全な遠隔地に保存
- 復旧に時間がかかる
コールドサイト
- 遠隔地に最低限のインフラだけを確保
- 復旧にハイスペックな要因が必要
ウォームサイト
- 遠隔地に同じシステムを構築し、非稼働状態で待機
- コールドサイトほどはハイスペック要因でなくていい
ホットサイト
- 遠隔地に同じシステムを構築し、常時データレプリケーションも行い稼働させておく
- サービス停止時間がもっとも短い
- コストは一番かかる

おわりに

要件定義時に検討しておいたほうが良い運用項目 が非常に参考になりました！

冒頭でも書きましたが、
「運用で検討する事をまとめといて」みたいなときって何を考えたら良いんだろう...となりがち。

慣れなのかもしれないですが、まだまだ勉強と経験が必要だなと思いました＼(＾o＾)／

紹介

みんなが知っておくべき運用設計のノウハウ

posted with amazlet at 18.04.11

(2017-10-30)
売り上げランキング: 349

Amazon.co.jpで詳細を見る

2018-04-12

【設計】みんなが知っておくべき運用設計のノウハウを読んだメモ - 1章:運用と運用設計

設計運用

はじめに

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

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

必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...？

ローンチしちゃったから走りながら設定変える辛い...いや無理かも..

ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ... 　サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば

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

読んだ本

みんなが知っておくべき運用設計のノウハウ

posted with amazlet at 18.04.11

(2017-10-30)
売り上げランキング: 349

Amazon.co.jpで詳細を見る

読んだ感想

この章では運用や運用設計がどのようなものか、というのをわかりやすく解説されています。
個人的には1章を読むだけでも全体像がつかめて価値があるなと思いました。

1.1.運用とは

運用設計の必要性

利用者に安定性してサービスを提供するために、システムを安定して稼働させる、そのために運用設計をする必要がある

運用はローンチしてから始まる（当たり前だが作ってる人は意識しずらい）

運用担当者へ必要なフローや手順書などが渡される

運用に登場する人物

システム運用に登場する人物は以下の3人

運用担当者

監視オペレータ

保守担当者

それぞれが連携しあって行うのが運用であり、
現在のシステムでは、運用がITコストの大半を占める。

運用担当者

利用者からの問い合わせを行う「サービスデスク」

手順書を元に日時や週次で行う「提携作業」

依頼を元にアカウント作成、パッチ適用、ログ取得を行う「非定型型作業」

インシデントが集まるシングルポイントになることが多い

運用全体を把握する、システムにとって非常に重要な役割

監視オペレータ

不具合の監視

不具合時の一次切り分け

運用担当者へエスカレーション

不具合時の一次対応

不正アクセスなどのセキュリティ監視

保守担当者

障害発生時の部品交換

定期メンテナンス

1.2.運用設計とは

運用設計がなぜ必要？

システムが複雑化しているので運用担当者もすべてを把握するのは不可能

運用設計書は新たな運用担当者への指南書にもなる

運用担当者に必要な情報がまとめられている事でまよわない運用ができる

運用設計をする意味

障害が発生したときになにをすべきか事前に決めておく事で安定性が増す。
※ 障害発生時に都度考えるのはやばい

構築設計と運用設計の際

※ 個人的にはここが非常にわかりやすかったです。 ※ 書籍では「火災報知器」を例に差異をあげています。

構築設計

設計する項目

製品機能

スペック

設置場所

具体例

サイズはどのようなものか

設置場所はどこになるか

色はどのようにするか

音はどの大きさで鳴らすか

ボタンを押したらサイレンが鳴る事

ボタンを押したらランプがヒカル事

運用設計

設計する項目

誰が

どんな時に

何をするのか

具体例

誰がサイレンを解除するのか

誰が解除の承認をするのか

解除の手順はどのようなものか

※ システム的なものではなく運用フローに近い

※ 例えば、上長にメールを送る > 上長はメールをみて解除する、など

作動した場合の連絡先はどのようなものか

連絡を受けた担当者はどのような行動をするか

誰が定期的に動作を点検するか

1.3.運用設計担当者としてのプロジェクト参加

プロジェクト進行

プロジェクト進行は以下のような流れで行われる

システム基本計画

提案対応

要件定義

基本設計

詳細設計

テスト

移行

運用担当者は3. 要件定義以降から関わる事が多い

プロジェクト進行に対する成果物

※ 各フェーズ名 > 成果物 > 運用設計に関わる説明 というフォーマットで記載します

要件定義

要件定義書

システムに「何が」必要かをまとめた資料

非機能要件も記載する

性能/信頼性/拡張性/運用性/セキュリティ

「どのように」は基本設計で検討する

要件検討資料

RFP

議事録

基本設計/運用設計

基本設計書

要件を「どのように」実現するかをまとめた資料

構成、画面・帳票、データの概要、システム連携などの基本方針を記載する

パラメータやプログラム設計は詳細設計にて行う

運用設計書

「どのように」運用していくかをまとめた資料

基本設計書の一部になることもある

※ ユースケースに近いイメージ

運用開始後に運用担当者がシステムを理解できるために必要なドキュメント

詳細設計

詳細設計書

基本設計書を実現する方法や設定値を記載する

運用設計的には「運用フロー」「運用手順書」「台帳/一覧」なども該当する

パラメータシート

運用フロー

運用手順書

台帳、一覧表

テスト

テスト仕様書

テスト計画書

テスト結果報告書

問題管理票

移行

移行計画書

決められた時間での移行情報をまとめた資料

利用者や運用担当者の教育計画も記載する

他の成果物と関連性が低いため後半フェーズで作成する事が多い

運用受け入れチェックリスト

プロジェクトの登場人物

エンドユーザ（利用者）

プロジェクトオーナー（顧客）

プロジェクトマネージャー（PM）

インフラ構築担当（インフラチーム）

アプリケーション開発担当者（アプリチーム）

運用設計担当者（運用設計チーム）

※ SIer型と自社サービス型でも結構違うないう印象 * 自分は後者で働いているため、プロダクトオーナーやデザイナーの役割も重要ですよね

プロジェクト会議体

キックオフ

全体進捗会議

分科会

内部進捗会

内部資料レビュー会

打ち上げ

おわりに

運用や運用設計ってサービスが走り出してから考えてしまう事が多かったですが、
振り返るとやっぱり同じ数だけ失敗することが多いなーという感じでした。

自分の失敗 x 体系的に勉強すると、運用や運用設計の目的、大事さも改めてわかりますね。
火災報知器売ってからどう使うものか考えても遅いわけですねw

運用も設計が大事だなーと改めて通貫です＼(＾o＾)／

紹介

みんなが知っておくべき運用設計のノウハウ

posted with amazlet at 18.04.11

(2017-10-30)
売り上げランキング: 349

Amazon.co.jpで詳細を見る

2018-03-24

bundle installがrmagickでインストールできないのがImagemagick 7が原因の件 - `An error occurred while installing rmagick (2.16.0), and Bundler cannot continue`

mac Homebrew gem ruby

はじめに

ちょっとしたことをやろうとbundle installを気軽にしたところ
こんなエラーでコケました

$ bundle install

~ 省略 ~ 
An error occurred while installing rmagick (2.16.0), and Bundler cannot continue.
Make sure that `gem install rmagick -v '2.16.0'` succeeds before bundling.
~ 省略 ~

その際にちょっとはまったのでメモ

1. はまったこと

結果、あとでぐぐることにはなるのですが、
へたにエラー文字列にgem install rmagick -v '2.16.0'をやれよな！と出てくるのでそれを信じて実行しだしてハマります。

ちなみに実行してみた結果はこんな感じ

# 書いてあるとおりに実行すると...
$ gem install rmagick -v '2.16.0'
Building native extensions. This could take a while...
ERROR: Error installing rmagick:
ERROR: Failed to build gem native extension.

current directory: /Users/tweeeety/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/rmagick-2.16.0/ext/RMagick
/Users/tweeeety/.rbenv/versions/2.4.1/bin/ruby -r ./siteconf20180323-8727-1v6xnw6.rb extconf.rb

checking for clang... yes
checking for Magick-config... no
checking for pkg-config... yes
checking for outdated ImageMagick version (<= 6.4.9)... no
checking for presence of MagickWand API (ImageMagick version >= 6.9.0)... no
checking for Ruby version >= 1.8.5... yes
checking for stdint.h... yes
checking for sys/types.h... yes
checking for wand/MagickWand.h... no

Can't install RMagick 2.16.0. Can't find MagickWand.h.
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers. Check the mkmf.log file for more details. You may
need configuration options.

Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/Users/tweeeety/.rbenv/versions/2.4.1/bin/$(RUBY_BASE_NAME)

To see why this extension failed to compile, please check the mkmf.log which can be found here:

/Users/tweeeety/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/extensions/x86_64-darwin-13/2.4.0-static/rmagick-2.16.0/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in /Users/tweeeety/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/rmagick-2.16.0 for inspection.
Results logged to /Users/tweeeety/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/extensions/x86_64-darwin-13/2.4.0-static/rmagick-2.16.0/gem_make.out

なんでやねん！と思ってログを見るとこんな感じ

find_executable: checking for clang... -------------------- yes

--------------------

find_executable: checking for Magick-config... -------------------- no

--------------------

find_executable: checking for pkg-config... -------------------- yes

--------------------

configure_compile_options: checking for outdated ImageMagick version (<= 6.4.9)... -------------------- no

imagemagickのversionがダメみたい...!?

2. 対処法

調べるとrmagickはimagemagickのバージョン7に対応していないからとのこと

ログにもImageMagick version (<= 6.4.9) と出てましたね。

imagemagickのversionを確認する

とはいえ目で見てみないとわからないのでversionを確認してみます。

$ brew info imagemagick
imagemagick: stable 7.0.7-27, HEAD
Tools and libraries to manipulate images in many formats
https://www.imagemagick.org/

~ 省略 ~

確かに7.0.7-27です

また、imagemagickのコマンドである
convertコマンドを見てみるとこんな感じになっています。

# シンボリックリンクになっている
$ ls -al /usr/local/bin/convert
lrwxr-xr-x  1 tweeeety  tweeeety  42  3 23 22:36 /usr/local/bin/convert -> ../Cellar/imagemagick/7.0.7-27/bin/convert

これはなに

brewでinstallすると、/usr/local/Cellar配下に置かれます。
実行するコマンドは/usr/local/bin配下にあり、/usr/local/Cellar配下の実態へのシンボリックリンクになっています。

なので、imagemagickの6を入れてシンボリックリンクを貼り直せば良いです。

imagemagickのversionをさげる

ということで、任意のversionを入れてlinkを貼り直します。

# 念のため確認
$ ls -al /usr/local/bin/convert
lrwxr-xr-x  1 tweeeety  tweeeety  42  3 23 22:36 /usr/local/bin/convert -> ../Cellar/imagemagick/7.0.7-27/bin/convert

# 6をインストール
$ brew install imagemagick@6

# 最初にlinkをはずしておく
$ brew unlink imagemagick

# imagemagick@6をリンクする
$ brew link --force imagemagick@6

# 確認
# ../Cellar/imagemagick@6/6.9.9-39/bin/convertへのリンクになってる
$ ls -al /usr/local/bin/convert
lrwxr-xr-x  1 tweeeety  tweeeety  44  3 24 00:04 /usr/local/bin/convert -> ../Cellar/imagemagick@6/6.9.9-39/bin/convert

ここまできたら
gem install rmagick -v '2.16.0'をする必要はなく、
bundle installが通るようになります

注意

brew unlink をするまえに brew link をすると怒られます

$ brew link --force imagemagick@6
Linking /usr/local/Cellar/imagemagick@6/6.9.9-39... 
Error: Could not symlink bin/Magick++-config
Target /usr/local/bin/Magick++-config
is a symlink belonging to imagemagick. You can unlink it:
  brew unlink imagemagick

To force the link and overwrite all conflicting files:
  brew link --overwrite imagemagick@6

To list all files that would be deleted:
  brew link --overwrite --dry-run imagemagick@6

参考

おわり

ちょっとしたことでハマるーーーーーーー＼(＾o＾)／

2018-02-09

【CircleCI】CircleCI 2.0からはじめる個人での簡単なCI導入方法 - githubとの連携まで

CircleCI CI github

はじめに

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

f:id:tweeeety:20180209194628p:plain

アジェンダ

CircleCIとは

CIってなんぞや

CircleCIってなんぞや

CircleCIの特徴

CircleCIの料金

CircleCIに必要なもの

CircleCIを使ってみる

CircleCI/githubの連携を確認する

1. CircleCIとは

ここではCircleCIってこんなもの！とわかるような内容を簡単にまとめておきます。

CIってなんぞや

CI(continuous integration: 継続的インテグレーション)とはなんぞやというのは知ってる前提ですが一応載せておきます。
安定のwikipediaから引用..

CI（英: continuous integration）とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。
エクストリーム・プログラミング (XP) のプラクティスの一つで、狭義にはビルドやテスト、
インスペクションなどを継続的に実行していくことを意味する[1]。
特に、1990年代後半以降の開発においては、継続的インテグレーションをサポートするソフトウェアを使用する傾向が強まってきた。

引用: wikipedia

もうちょっとわかりやすい説明は以下のスライドのP6がわかりやすかったです。
こちらも引用させて頂きますが

CI(継続的インテグレーション)

コンパイル/テストといったビルド処理を頻繁に繰り返すことで問題の早期発見や品質改善を目指す手法

CIすると嬉しいこと

バグの早期発見

ローカルでテストをするのをうっかり忘れてもCIでテストが落ちたことを検知できる

仮想環境(CirlceCIのVM)という共通の環境でテストができる -「自分のローカル環境ではテストが通ったけど、何故か他の人の環境ではテストが落ちる」という問題を防げる、原因の追求がしやすい

引用: CircleCIを勝手に紹介・宣伝 + おまけ [OSC Hokkaido 2015 LT]

CircleCIってなんぞや

とうぜんといえばとうぜんですが、CIサービスです。
URLはこちら
https://circleci.com/

Jenkinsとの比較

他CIサービスのjenkinsと比較して一番にあがるのは、
Jenkinsは自前でJenkinsサーバを立てる必要があるのに対して
クラウドのwebサービスというところでしょうか。

CircleCIはwebサービスなので、
アカウント登録してクラウド上でCIを実行する形を取ります。

CircleCIアカウント

アカウント登録はgithubアカウントとの連携（登録）が必須になります。

CircleCIの特徴

特徴を列挙します

クラウド型のCI webサービスである

アカウント登録はgithub連携必須

コンテナ1つ無料、2つ目以降は有料

privateリポジトリでも無料

並列ビルドは有料

CircleCIのVMにSSHできる

githubの公開鍵でSSHでいる

CircleCIの料金

料金は公式サイトの以下のページで確認できます。
https://circleci.com/pricing/

コンテナが1つ、ビルド時間が1,500分（25時間）なら無料です。
コンテナを1つ増やすたびに$50ほどかかります。個人だと$50もまぁまぁしますね...

2018/01現在の料金体系について、無料版と最低価格の比較だけ載せておきます

-	free(1 Container)	2 Container
repos	無限	無限
users	無限	無限
build	1 monthに1500分のビルド時間	無限
container	1	2
concurrent build	1	2

CircleCIに必要なもの

すでに特徴でも書いていますがgithubアカウントが必要です。
でもそれだけ！！

2. CircleCIを使ってみる

使ってみる際のながれです。

① github上でアカウントを作る

② github上でciするrepository(circleciでいうプロジェクト)を作成する

③ CircleCI上でgithubアカウントと連携する

④ ローカルでリポジトリに設定ファイル（.circleci/config.yml）を作る

⑤ CircleCI上でbuild開始してみる

ということで、この流れで使ってみます。

① github上でアカウントを作る

省略します。
さすがにciしようというくらいならありますよね！

② github上でciするrepository(circleciでいうプロジェクト)を作成する

今回はこの記事用に作ったリポジトリを例に使います。
https://github.com/tweeeety/go-test-circleci-sample

中身はgoで書いたソースとtestです。

構成

$ tree .
.
├── README.md
├── sample01.go
└── sample01_test.go

sample01.go

package sample01

func HelloWorld(s string) string {
  return "hello world, " + s
}

sample01_test.go

package sample01

import (
  "testing"
)

func TestHelloWorld(t *testing.T) {
  actual := HelloWorld("hoge")
  expected := "hello world, hoge"
  if actual != expected {
    t.Errorf("actual %v\nwant %v", actual, expected)
  }
}

③ CircleCI上でgithubアカウントと連携する

ここからCircleCIとgithubの連携です。

公式ページも再掲します。
https://circleci.com/

Sign Up

まずはgihubアカウントを利用してSign Upします

メニューPricingから行ってみます
freeで始めてみるのでそのままSign upします
Sign Up with GitHubからGithubアカウントにてAuthorizeします
Authorizeを求められるのでAuthorize circleciをクリックします
githubのパスワードを入力すれば登録完了です。簡単ですね！！
登録できればCircleCIのDashboard画面が開きます

ciするプロジェクトを選択

利用できる準備は整ったので、CircleCI上でプロジェクトを選択します。

CircleCI上ではPROJECTSといいますが、
githubのrepositoryのことです。

Add projectsからci対象とするprojectsを登録します
ciするプロジェクトのSetup projectを選択します
これでciの準備が整いました。今回は設定はこのまま進みます

④ ローカルでリポジトリに設定ファイル（`.circleci/config.yml`）を作る

最後に開いた画面の説明の通り、
リポジトリ直下に.circleci/config.ymlを追加します。

Sample .yml Fileには以下のように表示してくれているのでこれをコピって作ります。

# Golang CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-go/ for more details
version: 2
jobs:
  build:
    docker:
      # specify the version
      - image: circleci/golang:1.8
      
      # Specify service dependencies here if necessary
      # CircleCI maintains a library of pre-built images
      # documented at https://circleci.com/docs/2.0/circleci-images/
      # - image: circleci/postgres:9.4

    #### TEMPLATE_NOTE: go expects specific checkout path representing url
    #### expecting it in the form of
    ####   /go/src/github.com/circleci/go-tool
    ####   /go/src/bitbucket.org/circleci/go-tool
    working_directory: /go/src/github.com/{{ORG_NAME}}/{{REPO_NAME}}
    steps:
      - checkout

      # specify any bash command here prefixed with `run: `
      - run: go get -v -t -d ./...
      - run: go test -v ./...

.circleci/config.ymlの作成

yamlはコピーしますが、working_directoryの今回用に作ったリポジトリに変えておきます。

working_directory: /go/src/github.com/{{ORG_NAME}}/{{REPO_NAME}} ↓ working_directory: /go/src/github.com/tweeeety/go-test-by-circleci-sample

# リポジトリに移動してファイル作成
$ cd [path to repo]
$ mkdir .circleci

# 内容はそのまんまコピー
# working_directoryだけ自分のリポジトリに
$ vim .circleci/config.yml

# 普通にpush
$ git add . 
$ git commit -m 'add .circleci/config.yml'
$ git push origin master

⑤ CircleCI上でbuild開始してみる

Start buildingを押すと、追加した設定を元にciのbuildを実行してくれます。
f:id:tweeeety:20180209195124p:plain

CIが回ってtestが成功すればSUCCESSと表示されるのが確認できると思います。 f:id:tweeeety:20180209195136p:plain

3. CircleCI / githubの連携を確認する

githubとの連携も確認してみます。

github上からpull requestを送ったらciが回る、みたいなやつですね。
特別な設定はいらず、ここまでの設定にてすでにそうなっています。

pullreq作る

用意したリポジトリにためしにpull requestを送ってみます。

$ git checkout -b sample-branch

# 適当に編集
$ vim README.md

# pull request送る
$ git add .
$ git commit -m 'modify readme'
$ git push origin sample-branch

このあとはgithub上でpull requestを作成します。

CircleCI上でbuildがまわる

pull requestの作成をトリガーに、CircleCI上でbuildが回ります f:id:tweeeety:20180209195154p:plain

github上に結果が表示される

また、CircleCIでbuildがまわったと同時に
pull request上には結果が表示されます。
f:id:tweeeety:20180209195211p:plain

補足 - build結果のslack通知

この記事では基本的なciの連携までを書きました。

このあとはbuild結果をslackに通知したりしたいですよね。
その辺は別記事で書いてみました。
【CircleCI】CircleCI 2.0からはじめる個人での簡単なCI導入方法 - Build結果をSlack通知

おわり

jenkinsと違って自分で立てなくて良いのでサクっとはじめられますね！＼(＾o＾)／

2018-02-04

【ruby】プログラミング経験者のためのRUBY最速入門を読んだメモ

ruby 書籍

はじめに

rubyはこれまで必要な時に見よう見まねでなんとなくちょい修正、程度に触ってました。

まともに勉強したことはなかったので
プログラミング経験者のためのRUBY最速入門という本を読んでみたのでそのまとめです。

プログラミング経験者のためのRuby最速入門

posted with amazlet at 18.02.03

(2017-08-27)
売り上げランキング: 3,272

Amazon.co.jpで詳細を見る

所感

タイトル通り、
他の言語を触ってる人ならかなり早く読めます。
1,2時間程度でも読めると思います。

基本中の基本文法がコンパクトにまとまっていてとても良かったです。

まとめ

もともとコンパクトにまとめてくれてる本なので、
それをさらにまとめたというよりは自分用メモです。

導入

文法

演算子とデータ型

制御分

組み込みオブジェクト

1. 導入

rubyを入れて使ってみれるようにするまでです。
フレームワークなどを入れる/触るわけではないのでさらっと終わります。

homebrew

自分はすでに入ってたので飛ばしましたが一応...

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

参考: http://tweeeety.hateblo.jp/entry/2014/10/03/195429

rbenv

rbenv経由でrubyを入れます。
自分はhomebrewで直接rubyを入れてたのでrbenvで入れ直しました

# rubyのバージョンを確認
$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin13]

# rbenv install
# upgradeは10分弱かかったのでコーヒーでも飲みながら...
$ brew install rvenv

$ rbenv -v
rbenv 1.0.0

$ brew upgrade rbenv

# rbenv経由でのrubyのinstall
# これは3分くらいだったかな
$ rbenv install 2.4.1

# rubyのversionを2.4.1に切り替え
$ rbenv versions
  system
  2.1.2
* 2.2.0 (set by /Users/tweeeety/.rbenv/version)
  2.4.1

$ rbenv global 2.4.1

$ rbenv versions
  system
  2.1.2
  2.2.0
* 2.4.1 (set by /Users/tweeeety/.rbenv/version)

補足

rbenvをinstall後に、~/.bash_profileなどに以下を追加する必要があります
追加後にsource ~/.bash_profileするのをお忘れなく

export PATH="$HOME/.rbenv/shims:$PATH"
eval "$(rbenv init -)"

2. 文法

変数と定数

ローカル変数

hoge = "hoge"

インスタンス変数

@hoge = "hoge"

クラス変数

class Foo
  @@hoge = 1
end

グローバル変数

$hoge = 100

定数

HOGE = "hoge"

ちょいメモ

先頭が大文字

再代入可能

単行コメント

# コメント

複数業コメント

=begin
ここから
コメントや
＼(＾o＾)／
=end

記述以降を全てコメント

hoge = "hoge"
fuga = "fuga"

__END__ 
これ以降は
コメントや
＼(＾o＾)／

関数

def メソッド名(arg1, arg2, ...)
  # 処理
end

ちょいメモ

引数は「参照渡し」

到底の意味をもつ関数名の末尾に感嘆符（!と?）を付与する慣例がある

標準出力

puts

puts "hogehoge"

nilを返す

最後改行される

print

puts "hogehoge"

nilを返す

最後改行されない

p

p "hogehoge"

引数の値を返す

最後改行さる

3. 演算子とデータ型

演算子

他の言語とほぼ同じです。
あげてくれているサイトがあるので参照だけしておきます。
Ruby 2.5.0 リファレンスマニュアル > 演算子式

三項演算

条件 ? 式1 : 式2

文字列演算

文字列は + で連結します。
また、*で繰り返しができます。

連結と代入 というのがあり、これは知らなかったです。

a = "aiu"
b = "eo"

puts a << b # aiueo
puts a # aiueo

データ型

数値

全ての数値オブジェクトはNumericのインスタンス

Numeric       数値の親クラス
  ├ Integer   整数の親クラス
  │  ├ Bignum 大きな整数
  │  └ Fixnum 整数
  └ Float     浮動小数点

文字列

"（ダブルクオート）か'（シングルクオート）で囲む。
ダブルクオートで囲った文字列は式（#[式]）を埋め込める

# 式埋め込み例
hoge = "#[1 + 1]だよ" # print => 2だよ

配列

arr = ["hoge", "fuga", 1, true]

p arr
puts arr[0]

ハッシュ

member = {"hoge" => 20, "fuga" => 20}
puts member["hoge"]

型キャスト

# 文字 -> 数値
num = "1".to_i

# 数値 -> 文字
str = 1.to_s

クラス

# class定義
class Hoge
  def initialize(name, age)
    @name = name
    @age = age
  end

  def say
    puts @name + " is " + @age.to_s
  end

  # クラスメソッド
  def self.fuga
    puts "fuga!!!!"
  end
end

# インスタンス化
piyo = Hoge.new("piyo", 20)
piyo.say

# クラスメソッドの呼び出し
Hoge.fuga

モジュール

# module定義
module Mod
  Version = "1.0.0"
  
  def v
    Version
  end

  def say
    puts "this version is " + Version
  end

  def self.fuga
    puts "fuga!!!!"
  end

  # モジュールメソッドとして定義
  module_function :v
end

puts Mod.v
puts Mod::fuga

# (※1)これは怒られる
# puts Mod.say

# クラスにインクルード
class Cls
  include Mod
end

cls = Cls.new
puts cls.say
# (※2)これは怒られる
# puts cls.v

ちょいメモ

モジュールメソッドはmodule_functionを使う

モジュール名.メソッドで呼び出せる

プライベートメソッドになりインクルードしても呼べない

補足

(※1)これは怒られる の実行結果

module_sample.rb:25:in <main>': undefined methodsay' for Mod:Module (NoMethodError)

(※2)これは怒られる の実行結果

module_sample.rb:34:in <main>': private methodv' called for #<Cls:0x007fa9238f8c38> (NoMethodError)

オブジェクト

Objectクラスは全てのスーパークラス

nil

他の言語のnullと違い、nilはオブジェクト

4. 制御分

条件分岐

if文

if 条件式1 then
  # 処理1
elsif 条件式2 then
  # 処理2
else
  # 処理3
end

case文

case オブジェクト
when 値1 then
  # 処理1
when 値2 then
  # 処理2
when 値3, 値4, 値5 then
  # 処理3
else
  # 処理4
end

繰り返し

for

# よくある形
for 変数 in オブジェクト do
  # 処理  
end

# 範囲オブジェクト
for num in 1..3 do
  # 処理  
end

ちょいメモ

..は「範囲オブジェクト」

while

while 条件式 do
  # 処理

end

each

オブジェクトに対して何らかの処理を繰り返す場合使う

# 
オブジェクト.each{|変数|
  # 処理
}

#
オブジェクト.each do |変数|
  # 処理
end

loop

loop {
  # 処理
}

ちょいメモ

抜けるときはbreak

timesメソッド

一定の回数処理を繰り返す場合に使う

#
オブジェクト.times {|変数|
  # 処理
}

#
オブジェクト.times do |変数|
  # 処理
end

# 例
3.times do |i|
  putsh i # 1,2,3と出力
end

setpメソッド/uptoメソッド/donwtoメソッド

# stepメソッド
オブジェクト.step(limit, stepno) {|変数|
  # 処理
}

# 例
1.step(5, 2) {|i|
  puths i # 1,3,5と出力 
}


# uptoメソッド
オブジェクト.upto(max) {|変数|
  # 処理
}

# 例
2.upto(4) { |i|
  puth i # 2,3,4 と出力
}

# donwtoメソッド
オブジェクト.downto(min) {|変数|
  # 処理
}

# それぞれ`do |変数| 〜 end`の記述も可能

例外

# エラーの捕捉
begin
  # エラーが発生する可能性のある処理
rescue
  # エラーが発生した場合の処理
else
  # エラーが発生しない場合
ensure
  # 必ず行う処理
end

# エラーの発生
raise "error" # RuntimeError

ブロック

ブロックとは

関数やメソッドの呼び出しの際に引数と一緒に渡す処理のかたまり

以下の"do"から"end"までがブロック

[0,1,2].each do |i|
  puts i + 1
end

blockとyield

# 
def block_func(v)
  puts v

  # yieldを使うと関数内でブロックを実行可能
  # ブロックを受け取っていないと例外のため
  # block_given?とセットで使う
  yield if block_given?
end

# 呼び出し時二ブロックを渡す
block_func("hoge") do
  puts "fuga"
end

5. 組み込みオブジェクト

組み込みオブジェクトには以下のようなものがある

Numeric

数値を扱う基本クラス

数値処理のメソッドや演算子が実装されている

String

文字列を扱うクラス

文字列操作のメソッドや演算子が実装されている

Comparable

比較演算を許可するMix-in

NumericやStringも比較演算のためにインクルードしている

Regexp

正規表現を扱うクラス

リテラルは/(スラッシュ)

===、=~でパターンマッチ

Time

OS管理の時刻情報を扱うクラス

File

システム上のファイルを扱うクラス

IOクラスを継承している

Dir

ディレクトリ操作のためのクラス

Enumerable

オブジェクトの集まりを表現するMix-in

Struct

構造体を扱うためのクラス

その他

気になったコードだけ書いておいた、という自分用メモ https://github.com/tweeeety/book-ruby-sample

おわり

プログラミング経験者のためのRuby最速入門

posted with amazlet at 18.02.03

(2017-08-27)
売り上げランキング: 3,272

Amazon.co.jpで詳細を見る

自分のように、基本は他の言語だけどたまーに読み書きする程度で
ちゃんと勉強までしたことなかった、という人には
かなりすっきりさっくり読めてコンパクトなのでオススメです！＼(＾o＾)／

2018-02-03

【rbenv】rbenvで指定したrubyバージョンに切り替わらない時の対処法 - Homebrewで入れたrubyが原因編

ruby rbenv

はじめに

rbenvでrubyのversionを更新しようと思ったのですがなぜか切り替わらない....

昔も同じ事がありましたが、
今回はそれとは違い凡ミスでしたが小一時間使ってしまったので自分戒めメモ

最初に行った事

rbenvで切り替わらない系の記事は調べるとたくさん出てきます。

だいたいパスが通ってない場合が多いです。
昔同じ事があったと書きましたが、その時もこれでした。

ながれ

切り替え後にruby -vでバージョンを確認

切り替わってない

パスを確認

/Users/ユーザ名/.rbenv/shims/ruby になっていて欲しいがなってない

~/.bash_profileにパスを追加

sourceコマンドで反映をお忘れなく

再度ruby -vでバージョンを確認

切り替わってる...はずだった...

やるとこんな感じ

# 切り替えたはず
$ rbenv versions
  system
  2.1.2
  2.2.0
* 2.4.1 (set by /Users/hoge/.rbenv/version)

# 切り替わってない
$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin13]

# rubyのパスを確認すると違うところみてる
$ which ruby
/usr/local/bin/ruby

# ~/.bash_profileにパスを追加 ＆ 読み込み
$ vim ~/.bash_profile
---- vim ----
export PATH="$HOME/.rbenv/shims:$PATH"
-------------

$ source ~/.bash_profile

# 再度バージョン確認。変わってない...
$ ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin13]

参考

Rubyのバージョンが切り替わらない時の対処法！

正解

なんでだーーー
と思いながら小一時間なやみましたが凡ミスでした。

自分は以前、homebrewでrubyを入れたのですが、
その時に追加されたパスが悪さをしていました。

~/.bash_profile

# rbenv用に追加したパス
export PATH="$HOME/.rbenv/shims:$PATH"
eval "$(rbenv init -)"

~ 省略 ~ 

# 下の方にhomebrewのパス設定
# PATHの先頭にhomebrew用のパスが追加されて先に読まれてしまう
# これにより/usr/local/bin/rubyが読まれてしまう
export PATH="/usr/local/bin:$PATH"

確認

確認すると確かにhomebrewのrubyが使われています。

# rubyコマンドをあらためて確認
$ which ruby
/usr/local/bin/ruby

# lsで見てみるとhomebrewのrubyへのシンボリックリンク
# なるほど...
$ ls -l /usr/local/bin/ruby*
lrwxr-xr-x  1 hoge  admin  29  9  6  2016 /usr/local/bin/ruby -> ../Cellar/ruby/2.3.1/bin/ruby
lrwxr-xr-x  1 hoge  admin  44  1 24 03:55 /usr/local/bin/ruby-build -> ../Cellar/ruby-build/20171226/bin/ruby-build

切り替えられるようにする

homebrewで入れたrubyを消してもよかったのですが、
vimに必要だったりしたので素直にhomebrewのパス設定より後にrbenvのパス設定を追加するようにしました。

~/.bash_profile

# homebrewの設定
export PATH="/usr/local/bin:$PATH"

# rbenv用に追加したパス
export PATH="$HOME/.rbenv/shims:$PATH"
eval "$(rbenv init -)"

おわり

パスの上書きは気づきにくい！！＼(＾o＾)／

2018-01-23

【slack】slackの登録 on 2018年01月 - ワークスペースの作成

slack

はじめに

slack連携を試したくて改めて個人でslackを登録したのでメモ

2、3年前に作った時とはだいぶ変わってます... f:id:tweeeety:20180123234217p:plain

アジェンダ

SLackとは？

SlackのInterface

Slackのメンバー

ワークスペースの作成

Slackアプリでワークスペースを登録

1.Slackとは？

「チャットツールです以上！」という感じですが
公式からの引用を載せておきます

Slack とは一連の業務の拠点となるデジタルワークスペースです。
人々と組織、そしてツールをつなぐことで、作業効率を改善し、組織を活性化します。
引用: Slack って何？

SlackのInterface

画面的にはこんな感じです。

https://get.slack.help/hc/article_attachments/115015069663/WHAT_IS_SLACK_Slack_overview.png

1番左のレーン

ワークスペース

左から2番目のレーン

選択しているワークススペース内のチャンネル

選択しているワークススペース内の参加者

左から3番目（ど真ん中）のレーン

選択しているワークススペース内のチャンネルでの会話

一番右

設定など

Slackのメンバー

メンバーの種別には以下の5種類があります

ワークスペースのオーナー

ワークスペースの管理者

メンバー

マルチチャンネルゲスト

シングルチャンネルゲスト

これも公式からですが説明を載せておくとこんな感じ

種別	説明
ワークスペースのオーナー	セキュリティに関する項目や各種設定項目の中でも、重要な事項に関する管理権限を持ちますが、ワークスペースを削除する権限を持つのはワークスペースのプライマリーオーナー (通常はワークスペースの作成者)のみです。
ワークスペースの管理者	メンバーやパブリックチャンネルの管理、タスクや機能のメンテナンスなどを行うことができます
メンバー (デフォルト設定では全員がこの種別)	参加しているワークスペースのすべてのパブリックチャンネルへアクセスすることができます。
マルチチャンネルゲスト	使用する権限のあるチャンネルのみにアクセスすることができます。これらのチャンネルに参加しているメンバーに対してダイレクトメッセージを送信することができます
シングルチャンネルゲスト	割り当てられた1つのチャンネルのみにアクセスすることができます。このチャンネルに参加しているメンバーに対してダイレクトメッセージを送信することができます

引用: Slack メンバーの種別と権限

2. ワークスペースの作成

基本的には、これも公式の通りです。
読まずに作成画面から説明に従うだけでも簡単にできます。
引用: Slack ワークスペースを作成する

作成はこちら

作成画面はこちらから行います
https://slack.com/create

作ってみる

という事で実際に作ってみます。

簡単に説明

作成までのステップを先に説明しておくとこれだけです。

① Email入れる

これがワークスペースオーナーになります

② 名前とパスワード入れる

③ グループ名（ワークスペース名）入れる

ワークスペースの表示名であとから変更できます

④ ワークスペースのURL決める

これは世の中で唯一にする必要があります

あとから変更できません

⑤ そのままはじめたり、誰か招待したり

作る

① Email入れる

ワークスペースオーナー（今回は自分）のアドレスを入れます
画面が切り替わるので、Emailに届いた確認コードを入れます
嘘を入れていなければこういうメールが届いているはず！

② 名前とパスワード入れる

そのまま続きです
まずは名前を入れます
次にパスワードを設定します
簡単な質問を聞かれます

③ グループ名（ワークスペース名）入れる

グループ名を入れます
表示名なので他とかぶっても問題ありません

④ ワークスペースのURL決める

ワークスペースのURLを決めます
URLなので世の中でユニークな必要があります
悩むとしたらここくらいですかね
※ 画像のように既に使われていれば教えてくれます
OKであれば規約を確認します

⑤ そのままはじめたり、誰か招待したり

特に誰かの招待もいらなければ後でを選んではじめます
こんな画面が表示されれば完了です
そのまま使い方のチュートリアルも表示してくれたり

3. Slackアプリでワークスペースを登録

ここまでではあくまでもWebベースなので、
すでにSlackアプリを使っていれば登録します。

Slackアプリのワークスペース一覧の+ボタンを押すとこんな画面が表示されます。
f:id:tweeeety:20180123235129p:plain

先ほど決めたURLを入れるとEmailアドレスを聞かれます f:id:tweeeety:20180123235144p:plain

Emailを入れるとパスワードを聞かれるので
コレを入れてsign upすれば終わりです。お疲れ様でした！

おわり

目的はslackに登録する事ではなくて、
slack連携でいくつか試したい事があって登録しなおしたのですがだいぶ前と変わった印象！

前ってワークスペースじゃなくてプロジェクトって言ってませんでしたっけ...？記憶違いかな...!?
なにはともあれこの記事はこれでok＼(＾o＾)／

はじめに

読んだ本

もくじ

読んだ感想

2.1.要件定義とは

要件定義の注意点

2.2.機能要件/非機能要件

運用設計は非機能要件

要件定義時に検討しておいたほうが良い運用項目

BCP/DR

BCP

DR

DR対策

おわりに

紹介

はじめに

読んだ本

もくじ

読んだ感想

1.1.運用とは

運用設計の必要性

運用はローンチしてから始まる（当たり前だが作ってる人は意識しずらい）

運用に登場する人物

運用担当者

監視オペレータ

保守担当者

1.2.運用設計とは

運用設計がなぜ必要？

運用設計をする意味

構築設計と運用設計の際

構築設計

運用設計

1.3.運用設計担当者としてのプロジェクト参加

プロジェクト進行

プロジェクト進行に対する成果物

プロジェクトの登場人物

プロジェクト会議体

おわりに

紹介

はじめに

もくじ

1. はまったこと

2. 対処法

imagemagickのversionを確認する

これはなに

imagemagickのversionをさげる

注意

参考

おわり

はじめに

1. CircleCIとは

CIってなんぞや

CircleCIってなんぞや

Jenkinsとの比較

CircleCIアカウント

CircleCIの特徴

CircleCIの料金

CircleCIに必要なもの

2. CircleCIを使ってみる

① github上でアカウントを作る

② github上でciするrepository(circleciでいうプロジェクト)を作成する

構成

sample01.go

sample01_test.go

③ CircleCI上でgithubアカウントと連携する

Sign Up

ciするプロジェクトを選択

④ ローカルでリポジトリに設定ファイル（.circleci/config.yml）を作る

.circleci/config.ymlの作成

⑤ CircleCI上でbuild開始してみる

3. CircleCI / githubの連携を確認する

pullreq作る

CircleCI上でbuildがまわる

github上に結果が表示される

補足 - build結果のslack通知

おわり

はじめに

所感

まとめ

1. 導入

④ ローカルでリポジトリに設定ファイル（`.circleci/config.yml`）を作る