GitHub+Jenkins+Slackで継続的な開発

プログラミングとは、様々な言語があり悩むことが多いです。
しかし、その悩みに集中してプログラミングしたいものです。

ロジックの悩みだけではなく、ソフトウェア開発は環境の悩みも多くあったりするのです。

私は開発を継続するための環境選定で多く悩みました。
現在、安定して作業している環境をご紹介したいと思います。

GitHub

まず、ソースコードのバージョン管理で以下の要件がありました。

  • プライベートリポジトリを利用したい
  • GitHubにあるオープンソースを活用したい
  • CIを便利に行いたい
  • クラウドで管理したい

その結果、GitHubを選定しました。
プライベートリポジトリを無料で管理できるサービスも多々存在します。

などがそうです。また、GitLabについてはオンプレミスで利用することで、よりセキュアでかつ柔軟に構成することができます。
しかし、私はそれに魅力を感じませんでした。

やはり、GitHubにすでに存在するリソースを活用したかったり、多くの情報源があるGitHubに大きな魅力を感じました。
また、後記するJenkinsとの連携も非常に軽快です。

オンプレミスで構築することについては、管理面で悩まされると感じたので、クラウドで管理できる、GitHub.comがホストするBusiness Planに決定しました。  

ソースコードはOrganizationで全て管理し、OrganizationにはGSuiteと連携してSAMLでログインしています。
とっても便利なのですが、個人アカウントへのログインはSAMLで認証できないところが残念です。

ただ、GitHubのOrganizationでリポジトリ管理すると、Eclipseなどで扱う際にうまくPushできない場合がありました。
それについてはGitHubから提供されているDesktopアプリケーションでリポジトリ操作を行うことで解消できました。

CloneやPushなどはEclipseから実施せずに、このDesktopアプリで行う様に統一しています。

GitHubのIssuesや、Projectsはとても便利です。
また、覚書はWikiに書き溜める運用をしています。プログラミングにおけるハマりポイントなどは必ずWikiに書き残します。
一般公開してもいい様なネタはそのままブログの記事になって行きます。

Projectsは一見して状態が見えるので便利なのですが、Milestoneと併用してガントチャートなどになれば、顧客にも見せやすいのですが、その様な機能はZenHubなどを利用する必要がありそうです。

Jenkins

CIを行うためのサービスを色々と検討しました。
その中で、最終的に出した結論はJenkinsでした。
Jenkinsはサーバをこちらで用意する必要がありますが、Dockerを利用することで既存の環境を汚すことなく、容易に構築することができました。

環境構築のために、試行錯誤しているとどうしても不要なモジュールを入れてしまったり、シェルスクリプトで意図しない領域を汚してしまったりします。
Dockerであれば、何度でも作り直しできますし、作り直しの時間もごく短時間ですみます。

さらに私の環境では、DockerのSlaveとして、WindowsとMacを用意しています。これによって様々なプラットフォーム向けのアプリを継続的にビルドすることができます。  
  
また、最近のJenkinsでは「GitHub Organization Folder」というプラグインによって、GitHubとの連携が非常に容易になっています。
GitHubのOrganizationと連携することで、好きなトリガでビルドを走らせることができます。
さらにビルドの結果は、GitHubのコミットに紐づくので、そのコミットがビルドをパスしているのか容易に判断できます。

また、Jenkins Pipelineによって、リポジトリに「Jenkinsfile」を配置するだけでジョブとして生成されます。
そのため、Jenkinsの存在を意識せずに継続的な開発が可能になります。

安定するまで、Jenkinsの設定をあーだこーだといじっていましたが、現在ではほとんどJenkinsを参照することはなくなりました。
コミット、プッシュ、マージに対する付加情報となり、基本的にはGitHubだけを参照していれば作業を行うことができる様になるのです。
 
また、SAMLプラグインもありますので、G Suiteと連携してシングルサインオンで参照することもできます。
 
本当にシームレスです。
 

Slack

GitHubやJenkinsからの通知を全てSlackで受け止めています。
プッシュやマージをすると、Slackに通知がきますし、Issueを立ち上げても通知がきます。
必要なイベントはSlackだけを見ていれば良いというのは、本当に便利なことです。
  
私はプロジェクトで1チャンネルを用意し、そのチャネルへ当該プロジェクトの全てのイベントを送信しています。
  
ソースコードについてはこれらの方法で満足がいく運用ができています。
ただし、ドキュメントの管理方法については未だにベストプラクティスが見出せていません。
どうしてもMS Officeで作成するシチュエーションが多いため、バージョン管理をするとかえってわかりづらい場合もあります。
 
本当は全て、テキストで管理してバージョン管理も行いたいところです。
現状は模索中です。

それから、可能であれば顧客もSlackに招待する様にしています。
Slackに招待することで、やりとりが簡略化しますし、ファイルの受け渡しも容易になります。
セキュリティ上その様なことが困難なこともあるのですが、なるべくSlackでやりとりして行きたいものです。

あわせて読む

コメントを残す