前回の続き
今回、リニューアルを行うことになったきっかけは色々あるんだけれど、
主にタスク管理にRedmineを、ソース管理にGitを使いたかった点。
ところが、使っていたレンタルサーバではRedmineをインストールするには
Apacheのバージョンが古すぎる事が判明。
WordPressやプラグインも徐々に新しいPHPにしか対応しなくなってきていたので、
いっその事新しいサーバでやろうと思い、AWSでゼロから構築する事にしてみた。
構築には調べながらサボりながらの試行錯誤で、なんだかんだ１年かかった。
その試行錯誤の結果を備忘録がてら記録しておこうと思う。
やりたかったこと
ソース管理をGitにし、メインのリポジトリをクラウド上に設置する
これまで、ソース管理は自宅PCのApacheに立てたSVNで行っていた。
しかし自宅PCでは、自宅以外からのリポジトリアクセスが難しい。
また、自宅PCではPCが壊れたら終わり。バックアップ体制が心許ない。
それでなくとも、買い換えたりする度にリポジトリを移植するのもメンドくさい。
それならいっその事リポジトリをクラウド上に設置したかった。
Git自体はGitHubなんかでもいいっちゃいいんだけど、
運用面の練習がてら自分で構築することにした。
開発環境／公開環境の分離とリリース手順の簡略化のため、Jenkinsを設置する
これまでも自宅PCに開発環境、さくらのレンタルサーバ上に本番環境はあったが
リリース作業にFTPを転送したり、サーバ側での更新をローカルに反映する手順が煩雑で、
だんだんメンテナンスをサボるようになってしまった。
そこでライブラリの更新については、
- ローカル環境はWordPressの更新機能で更新して動作確認
- ローカルで動作確認できたものをGitにコミット
- クラウド上のテスト環境はGitからワンクリックでリリースして動作確認
- 本番環境へもワンクリックでリリース
をJenkins＋Gitで実現したかった。
また、これなら本番環境でUploadした画像などもライブラリ管理できるだろうと考えた。
タスク管理をRedmineで行う
これまでこのブログやメモでタスクを管理していたが正直言ってかなりやり辛かった。
またソースの変更とタスクを関連付けて管理するためにも、
RedmineとGitが連動する環境が欲しかった。
ちなみにやるまでは正直、「個人の開発でそこまで必要か？」とは思っていたのだけれど
実現して使ってみると、思いのほか快適だった。
やっぱりタスクをきちんと可視化しないと、やるべき事が見えづらく
作業が発散してしまったり、何をやりたかったかわからなくなってしまっていたのを実感した。
さて、実作業についての備忘録も書こうと思ってたけど
やりたいこと書いてたらそれなりに長文になってしまったので、今日はここまで。
続きはまた次回。
コメント