GitHub ActionsでStorybookを自動ビルドし、GitHub Pagesへデプロイする手順
今回の記事は、前回の記事「FigmaのデザイントークンからCSSファイルを自動生成し、Storybook化する手順」の続きの記事になる。前回は、ローカル開発環境でデザイントークンをStorybook化したが、今回はGitHub Pagesへデプロイし、URLアクセスでStorybookを閲覧できる
今回の記事は、前回の記事「FigmaのデザイントークンからCSSファイルを自動生成し、Storybook化する手順」の続きの記事になる。前回は、ローカル開発環境でデザイントークンをStorybook化したが、今回はGitHub Pagesへデプロイし、URLアクセスでStorybookを閲覧できる
この記事では、Figmaで定義したデザイントークンをCSSファイルに自動生成し、その結果をStorybookで視覚的に表示する手順を解説する。前提この記事は、前回記事「FigmaのデザイントークンからCSSファイルを自動生成する手順①【ローカル開発環境】」が完了していることを前提に
個人開発のプロジェクトで、プログラミングスクールの検索サイトを開発。これからプログラミングを学ぶ方の選択肢を増やすことを目的にスタート。2024年10月から法人としてサイトを運営し、デザインリニューアルや、コンテンツ拡充を予定。
ユーザーが使用する「フロントサイト」、検索サービスのデータを管理する「管理画面」の２つのサイトを使用し、共通のバックエンドに接続。
| プログラミング言語（フレームワーク, ライブラリ） | ■ フロントエンド HTML5 CSS3 TypeScript（React.js, Next.js） ■ バックエンド Node.js（Express.js） |
| 主なライブラリ | ■ フロントエンド MUI dayjs lodash react-redux react-hook-form react-markdown ■ バックエンド mongoose swagger-ui-express aws-sdk v3 crypto jsonwebtoken jwks-rsa |
| OS | Mac |
| インフラ | AWS
■ DB ■ ホスティング ■ メール配信 ■ ストレージ ■ 認証 |
| 各種ツール | ■ テストツール Playwright, Jest ■ バージョン管理/CI・CD GitHub Actions ■ プロジェクト管理/コミュニケーションツール GitHub, Google Chat ■ デザイン In Design |
これまでVue.js開発経験を応用し、Reactでのシステム開発を経験できました。検索サービスなのでSEOを考慮し、サーバーサイドレンダリングの実装をしたり、パフォーマンスを向上させるために状態管理（Redux）を導入したりと、ReactでWEBアプリを開発する上で必要なスキルを身につけることができました。また、VueとReactの両方を経験したことで、技術や設計の引き出しが増えたことも有益だったと感じます。このサイトは引き続き開発・運営をしてくため、Next.jsの新機能などは積極的に使っていきたいと考えています。
Node.jsを使用したバックエンドAPIの開発を通じて、効率的なデータ操作とセキュリティ対策を実施しました。認証・認可機能の実装や、swagger-ui-expressを用いたドキュメント自動生成により、開発効率を高めつつ、信頼性の高いAPIを提供しました。AWSのインフラ構築にも携わり、バックエンド開発からクラウドインフラの設計・運用まで、幅広く対応できるスキルを習得できました。
エンジニアとして、WordPressやShopifyを用いたコーポレートサイト、オウンドメディア、ECサイト制作/運用に従事。
赤枠が、私の位置です。
| プログラミング言語/フレームワーク | HTML5 CSS3 / Bootstrap, Bulma JavaScript / jQuery PHP / CakePHP SQL |
| ツール | ◾️バージョン管理 Git ◾️CMS WordPress, Shopify, CS-Cart ◾️プロジェクト管理 Wrike ■ デザイン Adobe Photoshop, Illustrator, XD |
この会社は、社員数が十数名規模の会社だったこともあり、すべての案件が社長を経由したものでした。これは、私が望んでいた環境でした。
というのも、「個人で稼ぐ」ことを意識している私としては、何年も会社を経営し、お客様から求められている社長が、どのような仕事の仕方をしているのかを学ぶことができたからです。メールのやり取り、商談一つとっても勉強になることばかりでした。ここで学んだ仕事のやり方を、副業で他のお客様にも提供し、評価をいただけたことで自信にもなりました。エンジニア以前に、一人のビジネスマンとしての基盤を、この会社での業務を通じて身につけることができたと思います。
この会社では、エンジニアがお客様のサポートや、マニュアル作成などの仕事を兼務していました。「手順書、ドキュメントを残すことは当たり前」という組織風土で働いたことで、「作業とドキュメント作成は常にセット」という意識が形成されました。
開発エンジニアとして複数の現場で仕事をしてきましたが、ドキュメントのない現場も多く、情報収集時間がかかったり、特定の業務が属人化されておりコミュニケーションコストを費やしたこともあります。
私の場合、自分の作業が少してもチームに影響を与える場合、手順書を残すようにしています。お客様に喜ばれることが多いので、指示されなくてもドキュメントを描く習慣は、私の強みだと思っています。
フロントエンドエンジニアとして、教育機関が使用する学習アプリやカルテシステムの開発に従事した。Nuxt3とTypeScriptを使った開発業務以外にも、API設計や、Playwrightを活用したE2Eテスト設計・プロセスの構築に従事。
| プログラミング言語（フレームワーク, ライブラリ） | CSS3（SCSS） JavaScript（Pug, Vue.js, Nuxt.js） |
| 主なライブラリ | pinia tailwindcss lodash
wijmo |
| OS | Mac, Windows |
| 各種ツール | ◾️テストツール Playwright ◾️バージョン管理/CI・CD GitHub, GitHub Actions ◾️プロジェクト管理/コミュニケーションツール Backlog, Slack ■ デザイン Figma |
開発しているアプリケーションのE2Eテストの設計と構築全般を担当しました。私主導でテスト設計をするのは初めての経験だったので、他の開発メンバーがスムーズにテストの作成ができるように意識をしました。
【チーム開発】E2Eテスト導入と運用をスムーズに進めるために意識していること
テストプロセス構築の過程で、Playwrightというツールにも詳しくなることができました。これまで、Cypressを使ったE2Eテストの構築は経験していたので、今後E2Eテストの構築を担当する機会があれば、これまでの経験を活かすことができると思います。
開発スタイルがデザイン→フロントエンドモック実装→バックエンドの流れだったこともあり、API設計に携わりました。フロントのモック実装を行う過程でデータ構成を決め、パラメーターやリクエストボディを決めていくイメージです。
API設計とテスト設計を経験したことで、これまでより少し上流工程に携わることができました。このフェーズでは、作業の基準が自分ではなく、「開発チームのメンバーにとってどうか」になるので、上流工程ならではの難しさもこの現場で感じることができました。
フロントエンドエンジニアとして、レース映像の配信アプリの開発に従事。
赤枠が、私の位置です。
| プログラミング言語（フレームワーク, ライブラリ） | HTML5 SCSS TypeScript（Vue.js） |
| 主なライブラリ | vuetify vue-router pinia vue-i18n aws-sdk dayjs lodash |
| OS | Mac |
| インフラ | AWS
■ DB |
| 各種ツール | ◾️ バージョン管理/CICD Bitbucket, CircleCI ◾️ プロジェクト管理/コミュニケーションツール Jira（Atlassian）, Confluence（Atlassian）, Slack ■ デザイン Figma |
Atomicデザインベースの「コンポーネント駆動開発」を採用している現場で、設計の引き出しを増やすことができました。それまで、Atomicデザインベースのコンポーネント設計は、コンポーネント構造のネストが深くなるので避けていたのですが、この現場での経験を通じて、「なぜ、やる必要があるか」を理解できました。特にComposition APIとの相性もよく、UIとロジックの分離やテストの容易性を高める上で、これから新規のシステムを開発する機会があれば、採用したい設計手法です。
また、コンポーネント設計/管理をチームで行う上で、「どのようなドキュメントがあれば、設計指針をチームで共有できるのか」についても学びがあり、今後の開発業務で活用したいと思っています。
この現場で開発したアプリは、リリース後にほとんどバグが出ることはありませんでした。
どの粒度でレビューをするのかは、現場によって違いますし、コードレビューを採用していない現場もあります。その中で、細かい粒度のコードレビューを経験できたことは大きな財産となりました。特に、「レビューをする」という場面においては、他の人が実装する機能についても仕様を把握し、レビューの優先度やチェックポイントを間違わないように注意しました。また、チームメンバーのモチベーションに配慮した指摘方法など、気を遣う場面も多く、ソフトスキルを向上させることができたと感じています。