DEV Community: puku

Angular/React両方を経験して得られた堅牢なアプリケーション設計

puku — Tue, 22 Sep 2020 03:02:51 +0000

Photo by All Bong on Unsplash

概要

アプリケーション開発において設計は非常に重要です。

本記事では Todo アプリを例に、これまで取り組んできた React アプリケーションのアーキテクチャや実装パターンを紹介します。

このアーキテクチャは筆者の Angular を用いたアプリケーション開発の経験が元になっており、Angular のオピニオンや Angular コミュニティで紹介された設計手法が含まれています。

コンセプト

コンポーネントとロジックの分離を基本とし、依存関係を単方向にします。

下記に実装例を示します。

Angular アプリケーションに適用した場合 https://github.com/puku0x/todo-angular
React アプリケーションに適用した場合 https://github.com/puku0x/todo-react
Vue.js アプリケーションに適用した場合 https://github.com/puku0x/todo-vue

Data

アプリケーション内で扱うデータは用途に応じて区別しましょう。

🤔なぜ？　
GET リクエストと POST リクエストで型が違うことはよくあります。また、API の仕様変更に柔軟に対応するためです。

Model

アプリケーションへの「入力」を表現するデータ型です。定数やAPI のレスポンス等が該当します。

interface Todo {
  id: number;
  title: string;
  completed: boolean;
}

DTO（Data Transfer Object）

アプリケーションからの「出力」を表現するデータ型です。API リクエスト等が該当します。

interface TodoCreateDto {
  title: string;
}

interface TodoUpdateDto {
  id: number;
  title: string;
  completed: boolean;
}

参考: CQRS, NestJS

Service

ドメインに関するビジネスロジックは Service に記述します。

実装は関数やオブジェクトでも構いませんが、class を用いた DI パターンは強力なのでお勧めです。

export class TodoService {
  constructor(private readonly http: HttpClient) {}

  fetchAll(offset?: number, limit?: number): Promise<Todo[]> {
    return this.http.get(url, params).then(/* 一覧データ */);
  }

  fetch(id: number): Promise<Todo> {
    return this.http.get(url, params).then(/* 詳細データ */);
  }

  create(todo: TodoCreateDto): Promise<Todo> {
    return this.http.post(url, body).then(/* 登録データ */);
  }

  update(id: number, todo: TodoUpdateDto): Promise<Todo> {
    return this.http.put(url, body).then(/* 更新データ */);
  }

  remove(id: number): Promise<number> {
    return this.http.delete(url).then(/* 削除されたデータのID */);
  }
}

// Axios や Fetch API のラッパー
export class HttpClient {
  ...
}

Service を実装する際は単一責任の原則を心がけましょう。CQRS に倣って入力と出力で分けても良いです。

この他、汎用的なロジックはユーティリティとして分離する場合があります。

export function debounce<T>(fn: (args: T) => void, delay: number) {
  let id: number | undefined;
  return (args: T) => {
    clearTimeout(id);
    id = window.setTimeout(() => fn(args), delay);
  };
}

参考: Introduction to services and dependency injection - Angular

Store

アプリケーション全体で使用する状態は Store に保存します。Store の実装は Angular では NgRx、React では Redux Toolkit + React Redux を使うと良いでしょう。

状態はイミュータブルかつ、Reducer が副作用を持たないように実装しましょう。フォームの状態は後述する Presenter 内で保持するのをお勧めします。

アプリケーションによっては Store が必要ない場合もあります。将来的に実装方法が変わる場合に備え、後述する Facade 等の中間層を作っておくと良いでしょう。

Facade

Facade は Store の実装をコンポーネントから隠すための中間層です。

Angular では Service、React では Hooks として実装すると良いでしょう。

export const useTodoListFacade = (arg: { offset?: number; limit?: number }) => {
  const { offset, limit } = arg;
  const history = useHistory();
  const location = useLocation();
  const dispatch = useDispatch<AppDispatch>();
  const todos = useSelector(todosSelector);
  const isFetching = useSelector(isFetchingSelector);

  const fetchAll = useCallback((arg: { offset?: number; limit?: number; } = {}) => {
    return dispatch(fetchAllTodos(arg)).then(unwrapResult);
  }, [dispatch]);

  const changeOffset = useCallback(
    (offset: number) => {
      const params = new URLSearchParams(location.search);
      params.set('offset', `${offset}`);
      history.push(`/todos?${params}`);
    },
    [history, location.search]
  );

  const changeLimit = useCallback(
    (limit: number) => {
      const params = new URLSearchParams(location.search);
      params.set('limit', `${limit}`);
      history.push(`/todos?${params}`);
    },
    [history, location.search]
  );

  useEffect(() => {
    fetchAll({ offset, limit });
  }, [offset, limit, fetchAll]);

  return {
    isFetching,
    todos,
    changeOffset,
    changeLimit,
    fetchAll,
  } as const;
};

Facade から Service を呼び出すこともあります。

参考: NgRx + Facades: Better State Management

Presenter

Presentational Component 内のロジックを抽出したものが Presenter です。

Presenter にはフォームの値やローカルな状態を持たせましょう。

interface FormValues {
  title: string;
  completed: boolean;
}

参考: Formik, React Hook Form

Angular では Service、React では Hooks として実装すると良いでしょう。

export const useTodoUpdatePresenter = (arg: { todo: Todo; onUpdate?: (todo: TodoUpdateDto) => void; }) => {
  const { todo, onUpdate } = arg;
  // const [counter, setCounter] = useState(0);

  // フォーム初期値
  const initialValues = useMemo(() => {
    return {
      title: todo.title,
      completed: todo.completed;
    } as FormValues;
  }, [todo]);

  // バリデーション用
  const validationSchema = useMemo(() => {
    return Yup.object().shape({
      title: Yup.string().required('Title is required.')
    });
  }, []);

  const formik = useFormik({
    enableReinitialize: true,
    initialValues,
    validationSchema,
    onSubmit: (values) => {
      const value = {...} as TodoUpdateDto;
      onUpdate && onUpdate(value);
    },
  });

  // const increment = useCallback(() => {
  //   setCounter(counter + 1);
  // }, [counter]);

  // const decrement = useCallback(() => {
  //   setCounter(counter - 1);
  // }, [counter]);

  return {
    ...formik,
    // counter,
    // increment,
    // decrement,
  } as const;
};

参考: Model-View-Presenter with Angular

Params

Params は Router から URL パラメータを取得し、Page Component に渡します。

Angular では Service、React では Hooks として実装すると良いでしょう。

import { useLocation } from 'react-router-dom';

export const useTodoListParams = () => {
  const location = useLocation();
  const params = new URLSearchParams(location.search);
  const limitParam = params.get('limit') || '10';
  const offsetParam = params.get('offset') || '0';

  return {
    limit: +limitParam,
    offset: +offsetParam,
  } as const;
};

ページネーションの状態や検索条件は URL パラメータに保存しましょう。

/users?offset=0&limit=10

Page Component

Page Component は Params から取得したデータを Container Component に渡します。

冗長に見えますが「Container Component 以下では既に URL パラメータが解決されている」という状況を作り出すことでデバッグやテストを容易にする狙いがあります。

import { TodoListContainer } from './containers';
import { useTodoListParams } from './todo-list.params';

export const TodoListPage = memo(() => {
  const { offset, limit } = useTodoListParams();

  return <TodoListContainer offset={offset} limit={limit} />;
});

Page Component は使い回さず URL 毎に作成しましょう。

/users/1

interface RouterParams {
  id: number;
}

export const useTodoDetailParams = () => {
  const { id } = useParams<RouterParams>();

  return { id } as const;
};

import { TodoDetailContainer } from './containers';
import { useTodoDetailParams } from './todo-detail.params';

export const TodoDetailPage = memo(() => {
  const { id } = useTodoDetailParams();

  return <TodoDetailContainer id={id} />;
});

参考: Angular Web アプリケーションの最新設計手法

Container Component

Page Component がパースした値を入力として受け取ります。

Facade 経由で Store の状態を Presentational Component に渡したり、Action を Dispatch したりします。

import { TodoUpdate } from '../components';

type Props = {
  id: number;
};

export const TodoUpdateContainer = (props: Props) => {
  const { id } = props;
  const { update } = useTodoUpdateFacade({ id });

  return todo ? <TodoUpdate todo={todo} onUpdate={update} /> : null;
};

URL パラメータの変更は Facade で行いましょう。

参考: Presentational and Container Components

Presentational Component

Model を描画するコンポーネントです。

前述した Presenter やユーティリティ、Service 内の静的メソッドを呼ぶ場合がありますが、基本的にPresentational Component にはロジックを書かず描画に専念させましょう。

import { useTodoUpdatePresenter } from './todo-update.presenter';

type Props = {
  todo: Todo;
  onUpdate?: (todo: TodoUpdateDto) => void;
};

export const TodoUpdate: React.FC<Props> = (props) => {
  const { todo, onUpdate } = props;

  const {
    errors,
    values,
    handleChange,
    handleSubmit,
    ...
  } = useTodoUpdatePresenter({ todo, onUpdate });

  return <>...</>
}

参考: Presentational and Container Components

スタイルガイド

ほぼ Angular coding style guide と同じです。これは、React に足りないオピニオンを Angular から取り入れることで意思決定コストを下げるという狙いがあります。

命名規則

Angular coding style guide に倣い、ファイル名は kabab-case に統一しましょう。この命名規則は検索性に優れるため Angular 以外のプロジェクトでも有用です。

Model: xxx.model.ts
Service: xxx.service.ts
Hooks: xxx.hook.ts
Presenter: xxx.presenter.ts
Facade: xxx.facade.ts
Params: xxx.params.ts
Store
- State: xxx.state.ts
- Selector: xxx.selector.ts
- Reducer: xxx.reducer.ts
- Action: xxx.action.ts
Routing Component: xxx.route.tsx
Page Component: xxx.page.tsx
Container Component: xxx.container.tsx
Presentational Component: xxx.component.tsx
Tests: xxx.service.spec.ts, xxx.component.spec.tsx

このほか、class 名やコンポーネント名は PascalCase、関数は camelCase に統一しましょう。

コンポーネント名のサフィックスは React の場合だと冗長なので消してしまって良いかもしれません。

// Angular
@Component({...})
export class TodoListContainerComponent {}
@Component({...})
export class TodoListComponent {}

// React
export const TodoListContainer: React.FC = () => {...}
export const TodoList: React.FC = () => {...}

参考: Angular, TypeScript Deep Dive

ディレクトリ構成

Model、Service、Store、Page を起点にドメイン別にディレクトリを分けましょう。ユニットテストはテスト対象となるファイルと同じディレクトリに配置します（コロケーション）。アプリケーション全体で共有するコンポーネントやユーティリティは shared 等に入れると良いでしょう。

- src/
  - models/
    - todo/
      - todo.model.ts
      - index.ts
    - index.ts
  - services/
    - todo/
      - todo.service.ts
      - todo.service.spec.ts
      - index.ts
    - index.ts
  - store/
    - todo/
      - actions/
        - todo.action.ts
        - todo.action.spec.ts
        - index.ts
      - reducers/
        - todo.reducer.ts
        - todo.reducer.spec.ts
        - index.ts
      - selectors/
        - todo.selector.ts
        - todo.selector.spec.ts
        - index.ts
      - states/
        - todo.state.ts
        - index.ts
      - index.ts
    - index.ts
  - pages/
    - todo/
      - todo-create/
        - components/
          - todo-create/
            - todo-create.component.tsx
            - todo-create.component.spec.tsx
            - todo-create.presenter.ts
            - todo-create.presenter.spec.tsx
            - index.ts
          - index.ts
        - containers/
          - todo-create/
            - todo-create.container.tsx
            - todo-create.container.spec.tsx
            - todo-create.facade.ts
            - todo-create.facade.spec.tsx
            - index.ts
          - index.ts
        - todo-create.page.tsx
        - todo-create.page.spec.tsx
        - todo-create.params.ts
        - todo-create.params.spec.tsx
        - index.ts
      - todo-detail/
      - todo-list/
      - todo-update/
      - todo.route.tsx
      - index.ts
    - index.ts
  - shared/
    - components/
    - hooks/
    - utils/
    - index.ts

参考: Angular, React

その他推奨する規約

TypeScript 自体の書き方に関しては TypeScript Deep Dive 等を参考にします。基本は ESLint/TSLint と Prettier によって自動的に決定されるため混乱は少ないと思われます。

Default export ではなく、Named export を使いましょう。

参考: なぜ default export を使うべきではないのか？ - LINE ENGINEERING

enum ではなく、union 型を使いましょう。

参考: さようなら、TypeScript enum - Kabuku Developers Blog

any ではなく、unknown を使いましょう。

その他

Routing Component

react-router-dom を利用する場合、ルーティング用のコンポーネントを作成する場合があります。Angular の xxx-routing.module.ts に相当します。

import { TodoCreatePage } from './todo-create';
import { TodoDetailPage } from './todo-detail';
import { TodoListPage } from './todo-list';
import { TodoUpdatePage } from './todo-update';

export const TodoRoute: React.FC = () => {
  return (
    <Suspense fallback={<div>loading...</div>}>
      <Switch>
        <Route exact path="/todos" component={TodoListPage} />
        <Route exact path="/todos/new" component={TodoCreatePage} />
        <Route exact path="/todos/:id" component={TodoDetailPage} />
        <Route exact path="/todos/:id/edit" component={TodoUpdatePage} />
      </Switch>
    </Suspense>
  );
};

バンドルの肥大化を防ぐため、Routing Component は必ず動的インポートしましょう。Page Component も同様にすると良いでしょう。

export const TodoPage = React.lazy(() =>
  import('./todo.route').then((m) => ({ default: m.TodoRoute }))
);

アプリケーション全体のルーティングを管理するコンポーネントに渡します。

export const App: React.FC = () => {
  return (
    <Suspense fallback={<div>loading...</div>}>
      <Switch>
        <Route path="/todos" component={TodoPage} />
        <Route path="/users" component={...} />
        <Route path="/settings" component={...} />
      </Switch>
    </Suspence>
  );
};

tsconfig.json

any を許可しないようにしましょう。

"compilerOptions": {
  "strict": true
}

Atomic Design

非推奨です。アプリケーションの実装に持ち込まないようにしましょう。

Atomic Design はコンポーネント指向を理解するのに有用ですが、コロケーションが崩れたり、粒度に関する不要な議論が増えるなどのデメリットがあります。

Atomic Design のような設計手法が必要になるのは UI ライブラリを構築する時と考えられますが、その場合のディレクトリ構成は以下のようにすると良いでしょう。

- libs/
  - ui-components/
    - button/
      - button.component.tsx
      - button.component.spec.tsx
      - index.ts
    - icon/
    - input/
    - search-input/
    - select/
        - option/
          - option.component.tsx
          - option.component.spec.tsx
          - index.ts
      - select.component.tsx
      - select.component.spec.tsx
      - index.ts
    - index.ts

components/molecules のように 粒度だけでディレクトリを分ける のは絶対にやめましょう。

参考: AtomicDesign 境界線のひき方

ビルドツール

create-react-app を使ってビルドした場合、MIT ライセンスに違反するため、eject して webpack.config.js を修正するか、Nx 等の他ツールに移行するのを強くお勧めします。

参考: React License Violation

終わりに

React を始めた当初、アプリケーションをどのように設計すれば良いか分からず苦労しましたが、過去に携わった Angular アプリケーションでの設計手法や Angular コミュニティを通して得た知識が役に立ちました。

本記事で紹介したアーキテクチャは React アプリケーション用に作成しましたが、もちろん Angular アプリケーションにも適用可能です。これから Angular や React で開発を始める際の参考になれば幸いです。

Angular アプリケーションに適用した場合 https://github.com/puku0x/todo-angular
React アプリケーションに適用した場合 https://github.com/puku0x/todo-react
Vue.js アプリケーションに適用した場合 https://github.com/puku0x/todo-vue

GitHub Actionsでリリース作業を省力化した話

puku — Mon, 20 Jul 2020 03:06:20 +0000

Photo by Ant Rozetsky on Unsplash

概要

現在開発中のアプリケーションでは、以下の様にブランチを分けています。

master（開発）
staging（動作確認）
production（本番環境）

開発が進むに従いアプリケーションのバージョンアップの頻度が上がっていきましたが、毎回のリリース作業が手動だったため面倒でした。

今回はリリースフローを自動化して作業の手間を減らしたお話をします。

記事の対象者

手動でバージョンアップやリリース作業を行っている方。

そう、あなたです。毎回のリリース作業、お疲れ様です。

TL;DR

結論を先に言うと、GitHub Actionsを活用することで作業の手間を1/3以下に、作業時間は10分程度（ほぼCI待ち）に短縮できました。

以下は今回の検証用のリポジトリです。
https://github.com/puku0x/github-pr-experimental/

新旧フローの比較は以下の通りです。

旧リリースフロー

 1. masterブランチをプル
 2. ローカルでバージョンアップ用のブランチを作成
 3. ローカルでバージョンアップコマンド実行
 4. 手動でコミット
 5. リモートにプッシュ
 6. 手動でmasterブランチにPull Request作成
 7. マージ
 8. 手動でRelease作成
 9. masterブランチをプル
10. タグから手動でstaging更新用のブランチ作成
11. リモートにプッシュ
12. 手動でstagingブランチにPull Request作成
13. マージ
    (自動でデプロイ)
14. 必要に応じてリリースノート追記

途中で読み飛ばしましたね？大丈夫、私もです。

一度のバージョンアップにかかる時間は20〜30分程度です。この例ではstagingブランチが対象ですが、productionブランチを含めるとさらに時間がかかります。

デプロイは自動化されていたものの、手順が多く作業に時間がかかることと、ローカル操作が多いためミスが発生し易いことが課題でした。

新リリースフロー

1. 手動トリガーでバージョンアップ実行
   (自動でmasterブランチにPull Request作成)
2. マージ
   (自動でRelease作成)
   (自動でstagingブランチにPull Request作成)
3. マージ
   (自動でデプロイ)
4. 必要に応じてリリースノート追記

ブランチ、Pull Request、Releaseの作成を自動化し、手動での作業を最小限にした結果、旧フローと比較して大幅に省力化しただけでなく、手作業によるミスを抑えることもできました。

新リリースフロー用のWorkflow

新リリースフローは下図の通りです。今回は青色で示された部分のWorkflowを作成します。

自動バージョンアップ

最初の課題はバージョンアップ作業の自動化です。幸い、コミットメッセージはConventional Commitsに準拠していたため、standard-versionで新しいバージョンの自動採番ができました。

未導入の場合は、まずここから始めましょう。

npm i -D cz-conventional-changelog

package.jsonにスクリプトと設定を追加します。

{
  "scripts": {
    "commit": "npx git-cz",
    "release": "npx standard-version --releaseCommitMessageFormat 'chore(*): bump v{{currentTag}}'"
  },
  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  },
  "standard-version": {
    "skip": {
      "tag": true
    },
    // lint-staged等を使用している場合は追加で設定
    // "scripts": {
    //   "postchangelog": "prettier --write"
    // }
  }
}

さらに、今年7月から使えるようになったWorkflow dispatchをトリガーとしてバージョンアップコマンドを実行するWorkflowを作ります。

# .github/workflows/bump.yml
name: Bump version

on: [workflow_dispatch]

jobs:
  bump:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: ['12']
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: actions/cache@v2
        id: cache
        with:
          path: node_modules
          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-npm-
      - name: Get branch
        id: get_branch
        run: echo ::set-output name=BRANCH::${GITHUB_REF/refs\/heads\//}
      - name: Switch branch
        run: git switch -c tmp
      - name: Git config
        run: |
          git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git config --local user.name "github-actions[bot]"
      - name: Setup Node.js ${{ matrix.node }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node }}
      - name: Install dependencies
        if: steps.cache.outputs.cache-hit != 'true'
        run: npm ci
      - name: Bump version
        id: bump_version
        run: |
          npm run release
          echo ::set-output name=VERSION::$(node -p "require('./package.json').version")
      - name: Push branch
        env:
          VERSION: ${{ steps.bump_version.outputs.VERSION }}
        run: |
          git branch -m bump-v${VERSION}
          git push -u origin bump-v${VERSION}
      - name: Create pull request
        uses: actions/github-script@v2
        env:
          BRANCH: ${{ steps.get_branch.outputs.BRANCH }}
          VERSION: ${{ steps.bump_version.outputs.VERSION }}
        with:
          #github-token: ${{ secrets.GITHUB_TOKEN }}
          github-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
          script: |
            github.pulls.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `chore(*): bump v${process.env.VERSION}`,
              body: `Bump v${process.env.VERSION}`,
              head: `${context.repo.owner}:bump-v${process.env.VERSION}`,
              base: process.env.BRANCH
            })

上記のWorkflowは、旧リリースフローの1〜6までに相当するもので、以下の処理を行っています。

1. tmpブランチを作成
2. npm run release実行（ユーザーはgithub-actionsに設定）
3. package.jsonから新しいバージョンを取得
4. 取得したバージョンを元にブランチをリネーム（bump-v1.0.0など）
5. リモートにプッシュ
6. Pull Request作成

なお、WorkflowによるPull Request作成をトリガーとして、他のWorkflowを起動するにはPersonal Access Tokenが必要になります。GitHub ActionsでCIを組んでいる場合は忘れずSecretsに設定しましょう。

自動Release作成

次はPull Requestマージ後にReleaseを自動作成するWorkflowを作ります。

バージョンアップ用のWorkflowで作成したブランチ名がbump-v.*.*.*となっていることを利用し、ジョブ実行の条件とRelease名、タグ名を設定していきます。

# .github/workflows/release.yml
name: Release

on:
  pull_request:
    branches:
      - master
    types: [closed]

jobs:
  release:
    if: github.event.pull_request.merged == true && startsWith(github.event.pull_request.head.ref, 'bump-v')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Get version
        id: get_version
        env:
          HEAD_REF: ${{ github.event.pull_request.head.ref }}
        run: echo ::set-output name=VERSION::${HEAD_REF#bump-v}
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          # GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
        with:
          tag_name: v${{ steps.get_version.outputs.VERSION }}
          release_name: v${{ steps.get_version.outputs.VERSION }}
          body: |+
            ## Bug fixes
            -

            ## Features
            -

            ## BREAKING CHANGES
            -
          draft: false
          prerelease: false

実行するとReleaseが作成されます。

Pull Request作成と比較すると簡単ですね。リリースノートの内容もよく使うものはあらかじめ載せておくと良いでしょう。

ところでReleaseのテンプレ機能はまだですか？

staging/production用Pull Request自動作成

いよいよ最後です。リリースの作成（=タグの作成）をトリガーとし、Pull Requestを作成するWorkflowを設定します。

# .github/workflows/bump-branches.yml
name: Bump branches

on:
  push:
    tags:
      - 'v*.*.*'

jobs:
  bump:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        branch: ['staging', 'production']
    steps:
      - name: Get version
        id: get_version
        run: echo ::set-output name=VERSION::${GITHUB_REF/refs\/tags\/v/}
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Push branch
        env:
          BRANCH: ${{ matrix.branch }}
          VERSION: ${{ steps.get_version.outputs.VERSION }}
        run: |
          git switch -c ${BRANCH}-v${VERSION} v${VERSION}
          git push -u origin ${BRANCH}-v${VERSION}
      - name: Create pull request
        uses: actions/github-script@v2
        env:
          BRANCH: ${{ matrix.branch }}
          VERSION: ${{ steps.get_version.outputs.VERSION }}
        with:
          #github-token: ${{ secrets.GITHUB_TOKEN }}
          github-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
          script: |
            github.pulls.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `chore(*): bump ${process.env.BRANCH} v${process.env.VERSION}`,
              body: `Bump ${process.env.BRANCH} v${process.env.VERSION}`,
              head: `${context.repo.owner}:${process.env.BRANCH}-v${process.env.VERSION}`,
              base: process.env.BRANCH
            })

実行すると、タグの命名規則（v.*.*.*）からstaging-v1.0.0のようなブランチを作成し、Pull Requestを作成します。

これで旧フローの9〜12まで自動化できました。あとはこのPull Requestをマージすればデプロイされます。

おわりに

GitHub Actionsを活用することで作業の手間を1/3以下に削減できました。また、作業時間については従来の20〜30分かかっていたものが10分程度までに短縮できました（ほぼCI待ち時間です）。

自動化により人間の仕事はバージョンアップのトリガーとマージだけとなりました。なんと楽なのでしょう。

みなさんも是非GitHub Actionsで快適な開発環境を手に入れましょう。

今回はWebフロントエンドアプリケーション開発用のWorkflowとして組みましたが、他の開発環境にも応用できるかと思います。

以下は今回の検証用のリポジトリです。ご参考までにどうぞ。
https://github.com/puku0x/github-pr-experimental/

Angular Strictモードまとめ

puku — Fri, 26 Jun 2020 16:03:19 +0000

Photo by Glenn Carstens-Peters on Unsplash

Angular v10 で --strict オプション有効時の設定がより厳格になりました。
https://angular.io/guide/strict-mode

ng new my-app --strict

TypeScript コンパイラ設定

strict: true

全てのstrictオプションが有効になります。

--noImplicitAny
--noImplicitThis
--alwaysStrict
--strictBindCallApply
--strictNullChecks
--strictFunctionTypes
--strictPropertyInitialization

forceConsistentCasingInFileNames: true

ファイル名の大文字・小文字が区別されます。

noImplicitReturns: true

関数の戻り値の型の省略が禁止されます。

// ❌ NG
ngOnInit() {
  // Do somthing
}

// ✅ OK
ngOnInit(): void {
  // Do somthing
}

noFallthroughCasesInSwitch: true

switch文のフォールスルーが禁止されます。

// ❌ NG
switch (value) {
  case 1:
  case 2:
    break
}

// ✅ OK
switch (value) {
  case 1:
    break;
  case 2:
    break
}

Angular コンパイラ設定

テンプレートの型チェックもより厳格になります。

"angularCompilerOptions": {
  "strictInjectionParameters": true,
  "strictTemplates": true
}

angular.json

Budgets

Bundle budgetとComponent budgetが75%程度削減されます。

非strict

"budgets": [
  {
    "type": "initial",
    "maximumWarning": "2mb",
    "maximumError": "5mb"
  },
  {
    "type": "anyComponentStyle",
    "maximumWarning": "6kb",
    "maximumError": "10kb"
  }
]

strict 有効

"budgets": [
  {
    "type": "initial",
    "maximumWarning": "500kb",
    "maximumError": "1mb"
  },
  {
    "type": "anyComponentStyle",
    "maximumWarning": "2kb",
    "maximumError": "4kb"
  }
]

tslint.json

"no-any": true

any の使用が禁止されます。

その他

"sideEffects": false

src/app に package.json が追加されます。

{
  "name": "my-app",
  "private": true,
  "sideEffects": false
}

※ webpackのTree Shakingの効率を高める効果があります。
https://webpack.js.org/guides/tree-shaking

Photo by Glenn Carstens-Peters on Unsplash