⛏️TSURUHASHI

顕在化していない投資不動産を見出し、買い付けを行うためのSFAツール

概要

投資不動産のマーケットに売りに出ている物件は、実は不動産全体の中の数パーセントにすぎません。世の中には「まだ売りに出ていない物件」が数多く存在し、それらをテクノロジーの力で見出して都市開発を進めるためにTSURUHASHIは2022年に生み出されました。

TSURUHASHIの開発についてはこちらのnoteをご覧ください。

開発の始め方

どのように開発を始めるか、READMEを一部公開します。

# tsuruhashi_app

Use Yarn Workspace to manage monorepo.

## apps

| name                       | desc |
| -------------------------- | ---- |
| @tsuruhashi_app/client     | -    |
| @tsuruhashi_app/client/api | -    |
| @tsuruhashi_app/server     | -    |

## dev user accounts

| role   | id                                    | password      |
| ------ | ------------------------------------- | ------------- |
| admin  | [email protected]  | zSH64Yz7mDtad |
| member | [email protected] | zSH64Yz7mDtad |

## preparation

```
yarn install
```

### Initialize .env files and databases

```
make init
```

### Database instances stop via docker compose

```
make stop-db
```

### Database instances start via docker compose

```
make start-db
```

## command

'run dev' on all apps

```
make run
```

client appllication: http://localhost:3000 \
client api: http://localhost:3002 \
server api: http://localhost:3001 \

## FAQ

### Q: What is the shoreman?

A: https://github.com/chrismytton/shoreman

> Starts the process formations defined in a `Procfile`.

こちらもtoggle sketch同様、いちいちローカルにチェックアウトせずにGitHub Codespacesで起動できるようになっているため、開発者は生産的でない開発環境の整備は必要ありません。

技術スタック

選定基準

当時の開発状況では、外部の会社を頼る必要があったため、カッティングエッジよりも普及したテクノロジーに振る、という判断で選定しました。

現在は管理画面系の開発に合わせて、新設のgeo_api側のサーバアーキテクチャに少しずつ寄せていくストラングラーパターンでバックエンド統合を進めようとしています。

全般

全方位TypeScriptで作ることとし、リポジトリはモノレポ構成です。

.
├── Makefile
├── README.md
├── apps
│   ├── client
│   ├── geo_api
│   └── server
├── docs
├── package.json
└── scripts

パッケージマネージャはyarnを使っており、workspaceの機能でモノレポの管理をしています。

フロントエンド

Next.js を採用しています。

バックエンド

Nest.js + TypeORM を主なコンポーネントとして採用しています。

インフラ（IaC）

「全方位TypeScript」の実践として Pulumi を採用しています。

Pulumi を採用したことで、インフラ関連の操作も単純なTypeScriptのプログラムに落とし込むことができ、自動化も一般的なTypeScriptのプログラムのビルドプロセスとほぼ変わらない形で実行できるようになっています。

また、後述のインフラへの更新反映などがシンプルになるのと、プログラマであってもインフラにどのようなものが展開されているのかという事を把握することができるようになりました。

リリース戦略

リリースノートの自動生成とビルド

リリース前にはその準備を自動で行うGitHub Actionsを用意しています。

このActionsを通じて

リリースタグの作成（いつのリリースかなどをわかりやすくするため、calvarを採用しています）
リリースノートの作成（前回のリリースノートからのマージ差分を抽出しての自動作成）
コンテナのビルド
ビルドしたコンテナをレジストリへプッシュ
GitHubのReleaseを作成

という一連の作業が行われ、フロントエンド、バックエンド、インフラへの反映準備ができます。

インフラへの更新反映

こちらもGitHub Actionsで実行できるように整備しており、↑の手順後に作成されたリリースの内容を本番環境に反映させることができるようになっています。

その時のリリースに、インフラへの変更を必要とする場合にはそのタグを指定してActionsを実行します。「Is dryrun?」のチェックを外さない限り本番環境への変更は行われないので、事前に実行してどのような変更があるかの確認も気軽に行うことができます。

データベースへの更新反映

MySQLのPaaSを利用しており、一般的なデータベース作業と同じく手順書を作成したうえでCLIを用いてリリース作業を行います。

バックエンドのデプロイ

現在はPaaSが提供するインプレースデプロイ機能を用いており、リリースに対応するコンテナをコンソールから指定してデプロイをかけています。

同時にPaaSのログストリームを確認しながら実施するやり方を取れるので、現状はこのやり方で不利益は出ていませんが、今後必要に応じてデプロイスロットを用いたBlue-Green Deployなどを検討することもあるかもしれません。

フロントエンドのデプロイ

フロントエンドへのリリースはGitHub Actionsを用いて行っており、こちらもリリースタグを指定して実行することでデプロイを行います。

フロントエンドのデプロイ環境はNodeなどを用いずにstatic buildしたものをデプロイする構成を取っているため、このActionsの中で静的サイトとして書き出しを行い、サーバへ展開しています。

最終更新 8 か月前