Successfully reported this slideshow.
Your SlideShare is downloading. ×

もっと早くに取り組んでおけばよかった開発プロセス

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 26 Ad

もっと早くに取り組んでおけばよかった開発プロセス

Download to read offline

『Weekdayランサーズ勉強会第1回 - 開発体制/プロセスについて』にて発表した資料。

『Weekdayランサーズ勉強会第1回 - 開発体制/プロセスについて』にて発表した資料。

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to もっと早くに取り組んでおけばよかった開発プロセス (20)

Advertisement
Advertisement

もっと早くに取り組んでおけばよかった開発プロセス

  1. 1. もっと早くに取り組ん でおけばよかった開発 プロセス 4 5 4 6 3 4 21 .
  2. 2. 参考 http://ecnomikata.com/
  3. 3. テモナ株式会社 テクニカル リーダー 高橋 和樹 社会人4年目 25歳 ITの世界で働きたくてインターン(PHP) 自分でサービスを作りたい 現職テモナ株式会社ではrailsに没頭 踊れるエンジニア Facebook : https://www.facebook.com/kazukiiin
  4. 4. もっと早くに取り組んでよかった開 発プロセスというテーマについて 1. 2013年7月当時のCTOが起業 2. その時点で開発経験3年未満のメンバーonlyのチーム 3. 開発メンバー3 ∼5人くらい 4. 同じミスは繰り返す 5. 改善は気持ちの問題 その場限りの対応で いっぱいいっぱい!! な状態の連続でした。
  5. 5. きっかけは救世主の登場 当社のイケてるCTO 中野 賀通(通称 ガッツさん) FaceBookID: nakano.noriyuki.1 CTOは C(ちょー)T(たのしー)O(お仕事) の略だよー
  6. 6. 既存のプロセスの問題点は沢山 あった。(今思えば・・・。) 1. 承認という名の自由? 承認フローはあるが機能していない 2. アップグレードの精度は、テスト担当のレベルに依存(ヒューマン エラーの発生) 3. 半年に一回のセキュリティテストの実施(それで大丈夫か?という問 題) 4. ソースコードの管理の手間 5. 死活監視ONLYの監視
  7. 7. 承認という名の自由?(1/5) • 承認はあるけれど機能していない 結果とし て事故が起きていた。 • 企画書・仕様書の徹底 • 単体結合テストの結果、セキュリティテストの結果 の添付 • データベース構成図、自動化テストの結果の添付
  8. 8. アップグレードの精度は、テス ト担当のレベルに依存(2/5) • 人が作ったものを人が検証する。 • その状態では必ずヒューマンエラーが発生してしまう。 • E2E(エンドツーエンド) テストの導入 • TestUnit ×SeleniumWebDriver(Ruby)で構築 • 受注から出荷までの流れを画面とDBから検証
  9. 9. [kazuki@takahashi-no-MacBook-Pro] ~/project/repeat/autotest % tree -L 1 (git)-[autotest2] . ├── README.md ├── data # test用のデータを格納 ├── document # documentを自動生成 ├── evidence # テスト結果を格納 ├── helpers # テストヘルパーを実装 ├── logs # テストの実行logを書き出し ├── pages # pegeごとの画面定義を記述 ├── rakefile # 実行用のrakeファイル ├── scinarios # テストシナリオ └── tools # クローラーによってpageオブジェクトを生成 PageObject デザインパターン
  10. 10. class OrderSpは スマートフォンにおける 注文フローの 操作をまとめるオブジェクト 画面の要素を 定数で定義するので 変更に強い!!
  11. 11. 半年に一回のセキュリティテス トの実施(3/5) • セキュリティテストを常に実施する環境を作 りたい • アプリ面 : OWASP ZAPを使ったリリース毎のテストの実 施 • サーバー面 : 脆弱性スキャナOpenVASによる定期的なセ キュリティチェック 有償のセキュリティチェックと合わせ て利用することによって安心が大きい!
  12. 12. http://www.owasp.org/
  13. 13. http://www.openvas.org/
  14. 14. SeleniumDriverを用いたブラウザテストに OwaspZAPをプロキシモードで起動しておき、 FireFoxで起動して、自動化テストを実行しつつ、 セキュリティテストも自動で行う。 ①プロキシモード で起動 ②Portを指定して接続 ③自動テストを実行
  15. 15. ソースコードの管理の手間(4/5) • リリース時のマージ作業が大変 • gitの導入
  16. 16. master preli dev リリー ス masterからブランチを作成して開発 localでテストが完了したらpreliにマージ リリース内容のすべてがテスト完了後 masterにマージ
  17. 17. 死活監視ONLYの監視(5/5) • 死活監視のみ 緊急事態しか検知出来ない • Zabbixでの監視の導入 • 監視用のControllerの実装で様々なシステムの 状態を検知する(WatchDogController)
  18. 18. http://www.zabbix.com/jp/
  19. 19. WatchDog(番犬) 異常が起きたよ!! 監視 検知!! 通知!! ・受注の状況 ・注文生成処理の監視 ・メルマガ配信の確認 etc…
  20. 20. 今後の改善 • GitHubに乗り換え(現状一部のソース) • chef-zeroですべての環境を管理 • Capistranoでデプロイ • Jenkins × ヘッドレスブラウザ × E2E
 で自動テストの自動実行の仕組みの構築
  21. 21. 1.承認という名の自由? 仕様書、テストパターンなどの document整備の徹底 2.アップグレードの精度は、テスト担当のレベルに依存(ヒューマ ンエラーの発生) 必須で検証が必要な部分はシステムで検証を 行う 3.半年に一回のセキュリティテストの実施(それで大丈夫か?という 問題) リリース毎にセキュリティの検証を出来る環境を整える 4.ソースコードの管理の手間 今の開発にGitは必須 5.死活監視ONLYの監視 番犬を置く、Zabbixで監視 まとめ
  22. 22. テモナで働いてみたい方はこちらへ http://www.temona.co.jp/recruit/

×