Skip to content

Latest commit

 

History

142 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

和楽知屋 -WaGotcha-

本アプリでの対応範囲

  • 企画・コンセプト考案(≒要件定義)
  • 設計書作成
  • モック作成
  • DB構築:PostgreSQL
  • バックエンド実装:Spring Boot
  • フロントエンド実装:Vue.js
  • コンテナ構築:Docker
  • 単体テスト:CI,JUnit5,Mockito
  • api
  • 結合テスト:Postman
  • クラウドサービス(本番環境)にデプロイ:AWS
  • システムテスト

※各テストについては初めは仕様書作成と手動でのテストをしつつ、段階的にテストツールの導入も進めています。

※今後の進捗に応じ更新していく予定です。

概要

和楽知屋 -WaGotcha-について

UI画像 和楽知屋(わがっちゃ)は和楽器業界に特化したX風アプリを想定し、必要な機能の実装を進めているSPAとなります。

名前の由来は"和楽器"と「わかった」を意味する"Gotcha"を組み合わせた造語で、和楽器愛好家やプロの投稿(ツツメキ)に対しいいね(WaGotcha)することで知見を広めたり交流を促せたらという思いを込めています。

現段階ではアプリの要となるCRUD機能としてツツメキ(Xでいうポストのこと)の投稿、表示、更新、削除まで実装しており、今後さらに機能を拡張させていく予定です。

ディレクトリ構成

同一リポジトリ内にAPIとフロントエンドのディレクトリを設け、それぞれの場所に移動することで1つのアプリケーションとして起動できるようにしています。

また、docsというディレクトリ内に各設計書やテスト仕様書のようなドキュメントをゼロから作成しマークダウン形式で見られるようにしています。

 WaGotcha/
    ├── docs/
    │   ├── screen-design/
    │   │   └── フロントエンドの設計書
    │   ├── api/
    │   │   └── RESTAPIの仕様書
    │   ├── db_schema/
    │   │   └── DB設計書
    │   ├── unit-test/
    │   │   └── フロントエンド、RESTAPIそれぞれの単体テスト仕様書と実施結果
    │   ├── integ-test/
    │   │   └── RESTAPIとDB、フロントエンドとRESTAPIとDBそれぞれの結合テスト仕様書と実施結果
    │   └── system-test/
    │       └── デプロイ実施後のシステムテストの仕様書と実施結果
    ├── api/
    │   └── Springを中心とするRESTAPIのソースコード
    ├── front/
    │   └── Vue.jsを中心とするフロントエンドのソースコード
    └── .github/
        └── workflows/
            └── 自動テストのワークフロー

開発手法としてのスタンス

他のリポジトリで公開しているレッスン記録アプリでは、前社で行なっていた業務をゼロから一人称で再現しポートフォリオとして構築することをテーマに設計からシステムテストまでの一連のプロセスを行いました。

今回のアプリでは一人称でゼロというスタンスを維持しつつ下記の3点を新たなテーマに進めています。

  • レッスン記録アプリでのプロセスをベースに、フロントエンドのフレームワークも導入することでSPA化させること

  • ウォーターフォール形式ではなく、機能を加えるごとに設計からテストまでを行うことで段階を追いながらXのような多機能アプリに近づけていくこと

  • アプリのターゲットを和楽器愛好家に据え、該当する人達に使いたいと思ってもらえるような機能や世界観を実装に落とし込むこと

技術スタック

使用技術

フロントエンド

  • HTML

  • CSS

  • JavaScript

  • Vue.js

    選定理由:SPAへの理解と実装のスピード感を優先し、追ってReact等を学習する際の足掛かりとするため

バックエンド

  • Java 21

  • Spring Boot 3.4.5

    選定理由:実務経験のあるフレームワークの実装能力を拡張するため

DB

  • PostgreSQL 14.15

    選定理由:中長期的により規模の大きなデータを扱うのを見据え引き続き基本的な構文に慣れるため

OS

  • macOS(ローカル開発)

  • Ubuntu(GitHub ActionsにてJUnit,Mockito使用時、AWSでのデプロイ)

    導入理由:自動テストの環境とAWSでの環境を統一させることでエラー対応の迅速化を図るため

インフラ管理

  • Docker 20.10.12

    導入理由(DB側):他のDB環境との競合を避けつつ、後にアプリ側がクラウドへとスムーズに切り替えられるようにするため

クラウド

  • AWS

    導入理由:複数のインスタンスを導入しつつ、自動デプロイも段階的に導入することで技術的幅を広げるため

コードエディター

  • Visual Studio Code

    選定理由:今後Java以外の言語を用いて開発することを見据えEclipse以外の環境を通して実装できるようにするため

テストツール

  • Postman
  • JUnit5
  • Mockito

主な機能

  • DBに登録されているツツメキ(Xでいうポスト)の表示、新規投稿、更新、削除

  • ツツメキ一覧と和楽知屋について解説した項目をシングルページで切り替える

デプロイ概要

構成図

構成図

デプロイ手順

ローカル開発

  • Vue.jsを用いてフロントエンドの実装
  • JavaとSpringを用いてRESTAPIを実装
  • テストツールを用いながら単体テスト、結合テストを実施

AWS環境構築

  • シングルAZ構成でパブリックサブネットとプライベートサブネットを作成
  • パブリックサブネットにEC2インスタンスを2台構築し、それぞれにSpringとVueの環境構築
  • プライベートサブネットにRDS(PostgreSQL)を配置しパブリックサブネットから接続、各EC2インスタンスからソースコードを起動

接続・動作確認

  • ブラウザでアプリが起動されることを確認
  • ローカルで開発していた時と同じように動作するかシステムテストを実施
  • UIや機能の改修・追加実装に伴い再度デプロイの実施

第1回デプロイ

  • 和楽知屋の考案
  • 必要最低限のCRUD機能を実装
  • JUnit,Mockitoの導入
  • 設計書の作成
  • AWSにてRDSを構築し、フロントエンドとバックエンドをそれぞれのEC2インスタンスにデプロイ

第2回デプロイ

  • 投稿内容の編集をキャンセルする機能の実装(APIとDBではキャンセル処理が行われるも、フロントでの反映がなされていなかった)
  • ボタンの配置と形状を変更

第3回デプロイ

  • 投稿されたツツメキ間の空白を削除
  • 投稿されたツツメキの角の丸みを除去

第4回デプロイ以降に向けた課題

CI/CDの導入

  • 最初のCRUD機能のテストではJUnitとMockito以外は手動で実施していたので、自動化での対応範囲を広げより効率よく進められるようにすることが課題であると考えています。
  • APIのデプロイ時に自動化を試みましたが難航したので.envの扱い方などを学習の上再度挑戦予定です。

さらなる機能追加

  • ログインや通知など、どういった機能を追加するかや優先順位を設け具体的な導入方法に落とし込むことが課題であると考えています。

フィードバックの収集

  • UIやどういった機能にニーズがあるかフィードバックを集め要件定義のような形へ落とし込みたいと考えています。

Releases

Packages

Used by

Contributors

Languages