« 2016年2月 | トップページ | 2016年5月 »

2016年3月の記事

gitbucketに移行した。

リポジトリ管理(成果物・版数管理)、と言うと、以前は Subversionが一般的だったかと思います。
それ以前はCVS、ずっと大昔(?)には、VSS(Microsoft Visual Source Safe)とか、SCCSRCSとか(ここまで来ると知らない世代が多そうですね)...。

現時点でのトレンドは、やっぱり Git/GiuHub でしょう

アスペアでも、社内的に利用しているクラウド環境上に持っていたリポジトリ管理環境は、つい最近までは Subvesionで構築していました。
環境を立ち上げたタイミングが数年前でしたから...

が、2016年・現在時点でのメンバー達のツール利用経験的には、Git/GiuHub経験者が殆ど。

社内的な可用性の点でも、ツール自体のメリット的にも Git の方が良いよね。
出来れば GitHub の方が良いかな?

でも、占有して使うには有料の Enterprise 契約しないといかんなあ...

じゃあ、GitHub close(少なくとも現在時点では)である、gitbucket を導入しちゃおう!
...という事になり、旧版のSubversion上のモノで、今後もメンテナンスを頻繁に行う予定のリポジトリは gitbucket に
移行しよう!
、ってことになりました。

各種調査&方針決め、環境構築は、アーキでもある山下さん
請負案件での開発(要求元との物理的な環境条件、セキュリティ的な要件などから、顧客先での開発が前提となった)が完了して、
次期案件が決まるまでの狭間の期間で、サクサクッと対応してくれました
中身の移行作業自体は、速形さんが実行してくれましたー)

かくして、社内的な保有リソースの管理も Git 相当のツールに統一した状態に移行しました。

ただ、今後の gitbucket の開発方向的に、「GitHub clone 路線から離れる」(GitHub管理側から、「Cloneとして開発を続けることは版権違反である」
旨で警告が有り、今後は gitbucket 独自での開発方向を目指す)...だそうで

この辺は、まあ様子見ですね。

要はメリット/デメリットを判断しつつ、柔軟に対応していければ良かろうと思います。
言い方を変えれば、柔軟な対応が出来なくなるほどの、組織の総合力としての学習・習得能力が下がるような事は避け続けて
行ければと思います。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

「ステキ!」大会・2015年度のメダリストは?

今時の大抵のIT企業なら自社・社員専用Webサイトを持っているかと思いますが、アスペアにも存在します。
 
オープンソースのCMSを使ってサイトを構築していますが、自社で作ったプラグインを1つ追加してます
 
その機能とは、「ステキ!」投票機能(by 渡辺さん)
説明するまでも無さそうですが、書込みを見たメンバー達が、「こりゃいいや!、ステキ!」と思ったら、記事の下にあるボタンをポチッと押せば
カウント数が上がっていく
という、Facebookやtwitterにある機能と同様のものです。
(同一人物が、同じ記事に何度も「ステキ!」することは出来ません)
 
で、年度毎に、誰が最も「ステキ!」を貰ったか?
を集計し、金・銀・銅のメダルを授与と共に発表することにしてます(去年から発表を始めました)
発表は3月の定例会で行いました(アスペアの年度は2月末が締めです)。
 
Dsc_0628 今年の銅メダルは、昨年・銀だった青柳さん(社長)
去年の写真でもカメラマン(撮影者は女性だったのでカメラウーマン?、実際にはフロントエンジニアのトミーです)をにらめ付けてましたが......
今年もかいっ!?
 
社長業で多忙を極めてますが、現在のアスペア内では恐らく一番「AWSに詳しい」と思われる人物でもあります。
 
さて銀メダルは、未だ幼いお子さんの子育ても忙しいJinさん
 
昨年の晩春に育児休暇から現場復帰したので、年度の途中から(アスペアの年度は3月頭開始)の書込みにも関わらず、
銀メダル獲得となりました!
見事なり!

.....なんですが、写真がありませんー。
 
発表を行った定例会当日は、町田ラボ内で対応している某社サイトの緊急不具合対応中!
元々が保育園の都合上、AM8:30からの業務開始を原則にしており、PM5:00を目処に帰宅します。
(定例会はPM5:00開始...)
不具合対応に目処がついた時点で、急いで帰宅されてしまいました。
 
はてさて!、金メダルの栄冠は誰の手に?
 
金賞は、同じ得票数で2名でした!
Dsc_0634 1人は、もうじき業界経験・丸2年を迎える速形さん
 
フリーな文章を書く事が、割と好きなように見受けます。
語彙や表現が、ちょっと同世代の大抵の人よりも豊富な感じ。
その独特の語り口(と言うか表現)をベースに、業務的な振返りや気付き、技術的な気付きやTips、
業務の改善のために Google Apps Script を自己判断で能動的に勉強&ツール作成&公開したり、
外部の勉強会(最近は「機械学習」がメインテーマ)に自ら参加して感想を上げてくれていたり、と、
思わず「ステキ!」せずにいられなくなるような記事(Web週報の中に"トピックス"欄があり、何を書いても良い)が頻繁に上がります。
 
Dsc_0631 金賞のもう1人は、ベテランの忠さん(結構、ノリがイイ)
 
要求定義からアーキテクトまでも担い、後進育成までしながらも、自ら簿記2級を目指して勉強中(3級は去年中に取得済み)
技術のみならず、顧客のビジネスを理解・把握する為の知識の1つと認識しての事です。
業務の方が決して暇という訳でもないのに、ランニングやジム通いをしながら簿記の勉強もしているという、
後輩を「自身の行動を以って指導する」ことが出来る、素晴らしい人です。
 
この、忠さんの週報:トピックスに限らず業務関係も含めて、とても面白い!
 
業務系に関しては、印象的なシーンを具体的:段落分けして簡易に時系列に&主観・客観的に書いてくれるので、
Web週報を介しての「間接的な疑似体験」をすることが出来ます!

これが素晴らしい!
 
リモートでありながらも、限定的とは言え体験&伴って忠さんの中にある暗黙知の動きを共有できる、ってのは
とても良いと考えてます!
 
前述の簿記の試験対策・準備・受験本番などに関しても具体的に書かれてます。
反省や良かった点、今後への見通しと改善の方策なども書いてあり、参考になりますね。
 
もう、これで「ステキ!」が付かないわけ無いだろう!、って感じです!!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

slackからGoogleDocs連携でラク~

チャットツールとしてslackを利用していますが、slackは各種API(WebアプリからPOSTする)が公開されています
アスペアでは Google Apps for Business も利用していますが、各種の申請書・報告書のフローは、Spreadsheet に Google Apps Script(GAP)を作り込むことで
事務方へのメール送信(GoogleドキュメントのURLを送る)したり、承認や差戻し、受領といったワークフローも実現してます
ただ、顧客先で終日の作業をするような場合、スマートデバイスだけでGoogleドキュメントを作成するのはちょっと辛い...
(勿論、雛形は用意してあるのですが)
slackに関しては、iOS も Android も対応アプリがあって便利に使える長文の入力には辛い場合が多いけど)。
それでは!?、ってことで
丁度、直前の請負案件(とは言え、顧客の要求との突合せ・確認・調整も有るので、顧客先での開発となった)が無事に終わって、
町田事務所に戻って来ていた山下さんにお願い!
slackで簡単な書式で呟けば、
自動的にGoogleドキュメント(休暇申請)が新規生成されて、事務方にURL通知(=申請文書)が発信され、
slack上に処理結果などが確認表示され、
なおかつ、申請者のGoogleカレンダーを自動更新するするという機能まで付けてくれました!

無論の事、半休とか、時刻指定などにも対応してくれてます(オプショナルな表記が可能な仕様です)
slack API も、GAP も触ったことが無く、今回が初めて
調査から入って、要求の整理、仕様の策定、内部処理の設計と実装、テストまで、
他の割込み作業(数時間とか半日とか)を含めてもサクッと3日で完成させちゃいました。
すげー!
Googleドキュメント(GAP仕込み)での従来のフローに加えて、問題無く併用することが出来ます。
(リリース同日中に、既に利用されてます)
使用方法や実装内容、今後の改変時における留意事項などのドキュメントも残してくれました!
すっげー!!(当り前の事だけど、良い心がけですよね?!)
今後も、slackからの連携処理は色々と企画・活用して行きたいですね!
エンジニア達の時間は、出来る限り有意義に活かしたい
退屈な操作や処理は、極力自動化・半自動化したいと思っています


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

2月の誕生日の人、その方は!?

現在の、アスペア内の2月生まれの人は忠さん(あだ名)のみ。

F1000628当月が誕生日である対象者が1名だけだと、「ハッピバースデイ、トゥーユー♪」を合唱する(定例会の最後に)際に、呼び名を誰が誰にするか?を
事前に調整する必要が無くて楽チン&安心です。

忠さんは、町田ラボ最大のお客様の顧客先稼働メンバーであり、グループの長です

アスペアでは、メンバーの育成や各メンバーの年次目標・キャリア目標の策定や達成の支援を行う為、
同じ現場内(顧客先・自社、共に)のメンバー達を「グループ」と呼び、
彼ら・彼女らの取りまとめを担うグループ長を(&場合により副グループ長も)設定しています

例えば考課面談などは、同じプロジェクト内で普段の稼働状況を最も把握しているはずなので、
現実的・実践的な評価やフォローが可能になります。

F1000625忠さんは、何処の顧客先・プロジェクトに参画しても、改善指向の視点や行動・実践を失わない人です。
その分、高稼働になったりもしますが、プロジェクトが(そのプロダクトの寿命範囲に於いて)トータルで
より良い方向に向かうよう、俯瞰的なドキュメントのリバース作成を提案したり(部分的に試作してから見て戴くなど、用意周到にしつつ)、
開発のフェーズ区切りなどでの「振返り」を提案したりといった付加価値的な行動で、
お客様からの信頼の厚い人です

当然ながら、ベースとしてのビジネス/業務把握から設計・実装、品質担保などの実力が前提になってます!

写真では分かり辛いのですが、実は結構ベテラン。

だけど、業務・日常の言動に於ける真摯な姿勢や、常に(大抵の場合に)前向きな捉え方、
新たな学習(必ずしも技術系に限らない:例えば簿記も現在は2級を目指してます(3級は合格済み))にも前向き
で、常に後輩の手本(モデル像)になる人物です。

F1000626で、忠さんを撮影しているのはトミー(フロントエンジニア)
ケーキのカット&撮影とか(実は、照明を落とした執務室に、ロウソクを灯したケーキを運び入れてくれるのもお願いした)、
色々とお世話してくれています。

座席の位置的に、どうしても頼み易い場所にいる(社内業務が多い)ので、ついつい毎回の定例会で、同じ役回りを頼むことになってしまってます。
申し訳ない...。

今月もキレイな&可愛いケーキですねー!
ケーキの準備は、毎回、業務推進部のSatさんにお願いしてます(セレクトも含めて!)。
ちなみに、ケーキは共済会の予算プールから供出してます

F1000627写真ついでに、社内の「お菓子場(珈琲メーカー設備アリ)」も掲載しちゃいましょう(恥ずかしながら...)。
珈琲は会費制。
お菓子は、皆で適当に摘みつつ、皆で適当に持ち寄るというファジーな運用で回ってます。

「町田ラボ」メンバー(他のプロジェクトの状況に応じてメンバー数が適宜で増減します)が結構多いし、女性の割合が高い点も効いてるのかも。
現在は割と充実してますね!("混沌としている" とも表現できますが)

いろいろと、可能な範囲で自由に楽しくやりつつも、一定のルールは設けている
そんな感じです。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

Capistranoでオートリリース!

全社定例会(と言っても、実質は勉強会に近い)の中の、ここ数ヶ月のレギュラーコンテンツで、
お題募集ディスカッション(以前は「即興ディスカッションと呼んでいた」)が有ります。

定例会の当日に参加者からディスカッション、或いは情報交換したい話題は有るか?、と問うて
出て来た話題についてディスカッションしようってのが当初の設定だったのですが、
どうも当日だとネタが出て来ない.....。

で、slack上に「ネタ投稿チャネル」を作っておき、思い付いたときに書き込んでおこうや!
って話になったんですが、残念ながら話題として使えるだけの書込みがなかったようです。

F1000635ので、長部さんの方で、以前の業務での経験から「Capistranoでオートリリースの実例」の紹介に端を発して、
ツールに拠る自動化に関するナレッジ共有を図ろうじゃないか、ってことになりました。

長部さんは、つい数か月前まで、某大手ECサイトの共通サービス開発・保守に関わっていました。
同じ客先に、結果的に5年以上いた(通常はこんなに長くは同一顧客先:同一サービスに関わりっ放しにはさせないのですが、「チームがとても気に入っている」という事で、無理くりアサイン先を異動して貰うことは避けて来ました...)ので、
運用方法の変遷にも詳しい。

以前はサービスの規模も大きくなかったので、手動リリースを2人組で相互チェックしながら作業していたとのこと。
(一旦運用が始まってしまえば、開発・保守で忙しい時でも継続的なリリースが発生するので、なかなか辛い...)

時と共に順調にサービスが大きくなり、物理サーバーの台数も増えたので、とても手動では追い付かなくなった
...と言うか、余りにアナクロ(=人物依存)なので、辛いしリスク高いしでやってられなくなった
(大量のコンソール(数十)を開いて、同じ作業をしなければいけない...)

そこで、デプロイ自動化ツールとして Capistrano(カピストラーノ)を導入したとのこと。
(他にも、fabricや、シェルスクリプトで対応してしまう手も有りますが...)
...と言っても、新たなツールの導入:フローの立上げには、それ自体に初期コストが掛かりますし、リスクも伴います
予算管理の責務を負っている上の人は、なかなかOKを出してくれない...。

そこで、従来の作業時間をストップウォッチで計って、総コマンド数を記録して現状のリリース運用のヤバさを説明したとのこと。
これで理解を得られて、晴れてツール導入に至ったとの事でした。

これで、コンソール1つで全サーバー環境へのデプロイ作業が効率的に行えるようになった!
 ・巻き戻しも簡単にできる。
 ・特定の実行権限・責任を負えるメンバーだけしかできなかったリリースが、マニュアルに従えば誰でもできるようになった。

デプロイのミスや、担当者不在によるアタフタも格段に減ったわけです。

この話を受けて、参加メンバーから他の顧客・プロジェクトでの話題共有が成されました

F1000632某社は、仕様的に近似点の多いサービスを複数の形態でリリースを行う必要が有り、作業が煩雑とのこと(紛らわしい)。
そこで.....
 ・ジェンキンスで自動化した。
 ・しくじった時の巻き戻しも楽ちん!
...とのことでした。

ビルドに数時間かかっていたのもが、Antを導入したら30分に短縮された例、とかも

ALTER文もふくめたリリースの自動化、巻き戻しも簡単操作で出来るプロジェクトがあった

どの案件に限らず、
リリース担当者が暗い顔をしていたら、これらのナレッジを持つ人達の協力も得つつ、必要な提案をしていければと思います!

ディスカッション、と言うか事例共有時のQAとして下記のようなものが有りました。

F1000631Q. DBカラムの追加変更と連動するリリースは?
 ⇒A. 先にDBカラムを追加しておき、後でそれを使うプログラムをリリースする
     ・MySQLの古い版では、ロックがかかるので、サービスへのアクセスの少ない時間帯に実行する。
     ・レコード件数の多い(数百万件以上の桁)テーブルは、カラム追加でなく、テーブル追加でしのぐ方向
     ・検証環境に大量件数のデータを入れて、サービス中の業務に支障が出ないかを事前に試す必要アリ

また、品質担保とコストメリットの狭間で揺れ動く例:
※JUnitと連動していたので、ビルドに時間がかかり過ぎて、いつ終ったのかわからない現場があった。
 ・昔作ったテストが動かないケースが多発して来たので、リリースに至るまでの連動からはずしたケースも。
   ・↑:元々は、自動テストがオールグリーン(OK)になるまでリリースできないルールだった...
 ・小さなサービスが次第に大きく成長したため、昔のテストが通らなくなるケースが多い

DevOpsという言葉で表現されますが、運用メンバーではなくてもリリース作業を行う例は多いのでは?
開発チームと運用チームとの間での実際のタスクの境界線は、その実施内容:リスクのバリエーション:伝達情報の量とコスト等から
判断されて、リリース辺りが境になるのでしょうね。

法的な問題も絡むようですが、リスクヘッジ(サービスを止めない)、コストメリットの点から判断・決定される例が
多いように思います。

視点を変えて言うと、アスペアメンバーとしては、DevOps全体として最適になる方向を俯瞰:提案できるように
ナレッジ共有・事例共有を進めたい
と思います!

長部さん、貴重なディスカッション:情報共有の機会を展開して戴いて、有難う御座いましたー!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

« 2016年2月 | トップページ | 2016年5月 »