こんにちは！こんばんは！プロトソリューション　技術広報の川満です！
今回の記事は先日12/18に開催された「Tech BASE Okinawa（テックベースオキナワ）」のレポートを参加者目線で投稿させて頂きます！
※弊社が運営している「CODE BASE OKINAWA」は主催団体として参加しています！

Tech BASE Okinawaって？？

新しい技術の学びを体験できる、沖縄最大級のエンジニア向けTechイベントです！これからエンジニアを目指す方・学生の方もお楽しみ頂けてる内容になっており、沖縄でトップエンジニアとして活躍されている方々からのトークセッション・参加者によるLT大会など様々な催しが開催されていました！

※詳しくはイベント情報へ

資料はこちらから

Session1

UZABASE 小副川 健さん
事業と共に育てる機械学習システムのこれまでとこれから

Session2

株式会社Alpaca Lab 松井 豊さん
日本一の禁煙アプリをつくっちゃった件

Session3

UZABASE 矢野 勉さん
プログラミング言語とシステムデザイン – Clojure, Java, DDD, Clean Architecture

Session4

株式会社プロトソリューション　比嘉 由紀さん
プログラム未経験の私がプログラミングと出会って人生激変した話

Session6

UZABASE 小玉 祐輝さん
Webアクセシビリティを身近にする

Session7

株式会社プロトソリューション　レッティグ・セバスチャン・ペーターさん
サーバーレスアプリケーションの開発とデプロイ
IaCを含む、スマートな環境構築の旅

Session8

株式会社Alpaca Lab 棚原 生磨さん
起業＆スタートアップで働くという選択肢

Session9

ちゅらデータ株式会社 真嘉比 愛さん
国内におけるAIの最先端事例紹介 〜2022年のトレンド予想を添えて〜

Session10

沖縄科学技術大学院大学(OIST)船井 正太郎さん
一人一人に寄り添う文章が書けるAIを目指して

Session11

株式会社 クアンド 西 孝幸さん
クラウドで手軽に始めるモダンなモニタリング

LT-1

CBcloud株式会社 新垣 雄志さん
データ指向プログラミング(仮)のススメ

LT-2

サイボウズ株式会社 西原翔太さん
草の根 IT コミュニティに着目した新しい郷土資料
流氷交差点

見所

Keynote Speech(基調講演)には和田卓人さんにご登壇頂きました！
企業の技術顧問を担当されており、テスト駆動開発の第一人者でソフトウェア開発に関わる書籍の執筆・監修もおこなっているTech業界を代表される方です！

他にもテックリードエンジニアの方や経営者の方も多数登壇されました！

Keynote

メインイベントのKeynoteが始まりました～！登壇者は前述で紹介させて頂いた和田卓人さん！
テーマは「堅牢なコードを書く – 例外、表明、契約による設計」です！
※大きな会場ですがほとんど席が埋まってますね・・・！

今回のテーマで重要な部分としてはコードの内側から品質をあげていこう。という点となり、

賢明なソフトウェア技術者になる為の第一歩は、動くプログラムを書くことと正しいプログラムを適切に作成することの違いを認識すること -M.A.Jackson(1975)-

引用コメントにある違いを埋める為にはどのような設計が必要なのか？というお話を以下3つのパートに分けてお話頂きました！

第1部：予防的プログラミング

処理の失敗は色々な原因が考えられるが、特に多いのがコードの使い方を誤った形で設計するという部分なのでそこに着目し、失敗しにくいコードを作る必要がある。その為には正しい予防的プログラミングの知識を身に着ける必要があるが、意外と誤った認識をお持ちの方が多いとの事・・・！

・プログラミングに対して防御的になること、つまり「そうなるはずだ」と決めつけないこと
・予防的プログラミングの根底にあるのは、他のコードのせいで不正なデータがあったとしても
　影響を受けないようにすること

上記は登壇されて際におっしゃっていた予防的プログラミングについてのコメントです！
確かに他に影響を受けないという観点は凄く大切だと思いますし、心理的なバイアスがかかって「だろう」的な考えで進めてしまう事は誰しもがあるはず・・・！勉強になります！！

第2部:攻撃的プログラミング

攻撃的プログラミング = 早めにクラッシュさせるような作りにする
・障害を抱えて中途半端に動いているプログラムよりも死んだプログラム方がダメージが少ない
・「あり得ない」何かが発生した際にプログラムは実行可能なもの（要望を満たせない）ではない
上記が定義となり、正当性と堅牢性のバランスが大事でクラスは正当性を重視し、アーキテクチャ/フレームワーク等で堅牢性を保証する事をおススメされていました！
正当性=確からしさ。不正確な結果を返すぐらいなら何も返さない方がよい
堅牢性=不正確な結果を返しても動き続ける

第3部:契約プログラミング

このパートも凄く響きました・・・！

不具合や欠陥を減らすために間違えにくい設計していく。但し一人一人が予防のみに固執してしまうと周りのメンバーを信用できなくなり、重複した作業が発生する事で内部品質(可読性や変更容易性)が下がってしまう。

これは恐ろしい。。。ですがありがちなのかなっと思いました。。
こちらについてのアクションは「誰が予防的or攻撃的プログラミングを担当する？何をやるべきか？を決め（信じる）契約による設計で要求されたこと以上・以下の事を行わない。」という事でした。
何事も自身と他者の役割を理解し、責任をもって業務に臨むことが大切なんだな。と強く思いました！！

Keynoteまとめ

予防的プログラミングで間違えにくいコードを書き、それでも障害が発生した場合を想定して攻撃的プログラミングの観点で早めにクラッシュ(影響を拡大させない・障害を早めに検知)させてしまおう！
但しきちんと自身・他者の役割を理解し、責任をもつ事が大切である！という所をしっかり意識していきたいと思えるとても身になる内容でした！

各Session

Keynoteも終了し、お昼は美味しいお弁当も頂けて満足★ご馳走様でした！！
午後もためになるセッションが目白押しです！！！

Session1

登壇者：UZABASE 小副川 健さん　
「事業と共に育てる機械学習システムのこれまでとこれから」
教師データに関する課題克服の体験談やこれから挑戦される目標を惜しげもなく発表されており、
今後機械学習システムを取り入れる際には要チェックだなと感じました！

Session2

登壇者：株式会社Alpaca Lab 松井 豊さん　
「日本一の禁煙アプリをつくっちゃった件」
強い信念に圧倒されましたし、アプリを作る上で大切な考え方を学ばせて頂きました！
エンジニアとしてはもちろん、人としても尊敬出来る温かい方でした！！

Session3

登壇者：UZABASE 矢野 勉さん
「プログラミング言語とシステムデザイン-Clojure,Java,デザインパターン,DDD,CleanArchitecture-」
言語毎の種類や特徴の違いについて発表して頂きました！凄い人の数・・・！

Session4

登壇者：プロトソリューション 比嘉 由紀さん
「プログラム未経験の私がプログラムと出会って人生激変した話」
プログラミング未経験の方にも希望を与え、現役の方も共感できる発表内容でした！
堂々と発表されてて、めっちゃかっこよかったです！！

Session5

登壇者： 株式会社 Solafune 光武 亨さん
「衛星データで地球をハックせよ！」
地球上のあらゆる事象をソフトウェアで制御可能にする。というMissionにロマンを感じました！

Session6

登壇者：UZABASE 小玉 祐輝さん
「Webアクセシビリティを身近にする」
プロダクトのアクセシビリティを高める為の施策や考え方を発表して頂きました！
私自身アクセシビリティに対して意識する機会が少なかったので勉強になりました！

Session7

登壇者：プロトソリューション　レッティグ・セバスチャン・ペーターさん
テーマ「サーバーレスアプリケーションの開発とデプロイIaCを含む、スマートな環境構築の旅」
最先端の技術を用いた環境構築の方法を発表されていました！皆様、興味深々！！

Session8

登壇者：株式会社Alpaca Lab 棚原 生磨さん
テーマ「起業&スタートアップで働くという選択肢」
企業立ち上げの経験談をお話頂けて、これから起業を目指している方にはぴったりな内容でした！
実績を出す為の取り組み内容がとても勉強になりました！AIRCLE私も使ってます！！

Session9

登壇者：ちゅらデータ株式会社 真嘉比 愛さん
テーマ「国内におけるAIの最先端事例紹介~2022年のトレンド予測を添えて~」
AIビジネス導入に関する課題や責任、最先端事例が聞けて難しい問題もありますがワクワクする内容でいっぱいでした！

Session10

登壇者：沖縄科学技術大学院大学(OIST)船井 正太郎さん
テーマ「一人一人に寄り添う文章が書けるAIを目指して」
文章を数値化し、学習させたAIがアウトプットした内容を人に理解させる事が出来るか？という実験結果や現在挑戦されている実験内容を発表されていて、QAエンジニアの私としては検証に近い実験のお話だったので興味深い内容でした！

Session11

登壇者：株式会社 クアンド 西 孝幸さん
「クラウドで手軽に始めるモダンなモニタリング」
マイクロサービス普及に伴う課題への取り組み内容をお話して頂きました！学ぶべき部分が多かったです！

参加者LT

全てのSessionが終わりまして(登壇者の皆様お疲れ様でした！！)、続いてはLT大会に移ります！

まずはCBcloud株式会社の新垣 雄志さんです！データ構造に着目した観点での発表でした！

続いてお二人目！UZABASE 二木 拓也（にっきー）さんです！
テスト駆動開発を認知～実践する中での気づきを発表して頂きました！

最後の登壇者の方です！サイボウズ株式会社 西原翔太さんです！
圧倒的な宣伝力でコミュニティのご紹介をされていて、聴き入ってしまいました！！

LT登壇者の皆様、本当にお疲れ様でした！！！

パネルディスカッション

続いてが最後の催し、パネルディスカッションです！！みんなで「沖縄テックの未来シナリオを考えよう！」
画像左側から・・・・
<モデレーター>
株式会社Link and Visible 豊里 健一郎さん
<パネラー>
プログラマー テスト駆動開発者 和田卓人さん、沖縄科学技術大学院大学(OIST)　船井 正太郎さん
UZABASE 林 尚之さん、プロトソリューション 仲濱 政治さん

テーマ①「多様化するエンジニアの働き方」

やはりお話の中心はコロナ禍に対する影響ですね！フルリモートへの切り替えはスムーズに行えており、海外やフリーランスのエンジニアの方とお仕事する機会は増え、通勤時間・移動費用が無くなった等のプラスの話題もありますが、コミュニケーションに関しての課題があり、出社する機会も作る等の工夫をされている方もいるようです！
コミュニケーションのコツという所で、GatherやVirbela等のバーチャルオフィス空間のサービスを利用されているなんてお話もされてて使ってみたいなーと思いました！

他にもテキストコミュニケーションのハードルを下げる(考えて文字を打たせない)文化を作る事で生の声を聞き取れる事が出来るようになる。絵文字を増やして感情のリアクションのバリエーションを増やすのもあり。というお話が出ており、凄く共感しました！※私もチームメンバーに対して出来るだけテキストコミュニケーションのハードルを下げられるように意識している。

テーマ②「これから活躍するエンジニアに求められること」

まず、沖縄IT産業の年間売上高は年々右肩上がりになっているが全国の労働生産性の順位としてはワーストになっているようです。。※悲しい
そういう背景も含め、県内で求められる人材像のアンケートを取った所以下の人材が上位に入っているようです！

・システム全体を俯瞰して思考できる人材
・上流工程の技術力を持つ人材
・最新技術を持つ人材

また県外の方から見ると沖縄のエンジニアはしっかり仕事をしてもらえるイメージがあり、可能性を感じているという声もありました！※素直にうれしい♡

Tech系のコミュニティに積極的に参加していき、求められる人材に近づきたいと思いました！

テーマ③「沖縄の未来をどう描いていく？」

コロナの影響でどこにいてもプログラミングが出来る状況が整備されており、沖縄という土地は魅力的だと思うので未来は明るい(人が集まりやすい)！ただ技術の教えを乞う（誰に聞けばよい？）機会が土地柄的に少ないのでコミュニティに積極的に参加し師匠(教えを乞える人)を見つけたり、技術を磨いていく必要はある。という話題で盛り上がっていました！土地の魅力に甘えず、自立性をしっかりと上げていこう！！

最後に

ディスカッションQ&Aも盛り上がりつつ、Tech BASE Okinawa の全プログラムが終了しました！
最初から最後まで勉強になりっぱなしでした！！参加応募総数も200名以上になり、大成功で終了しました！

今回このようなイベントに開催出来た事は沖縄全体に良い影響を与えられたのではないかと思います！
そして本イベントに参加された方はもちろん、運営チームの皆様本当にお疲れ様でした！！
次回の開催をお楽しみに！！！！

はじめに

前回のブログ記事では、FastAPIで画像内容を判定できるAPIを作成しました。そのAPIは、CloudFormationのテンプレートでAWS LambdaとElastic Beanstalkにデプロイしました。

今回のブログ記事では、AWS CodePipelineを使ってCI/CDプロセスを実装することで、そのAPIのデプロイを自動化します。

自己紹介

私はアダムと申します。PROTO SolutionのAIテクノロジー推進室で機械学習／深層学習のシステムやプロトタイプを開発しております。

主な仕事は、TensorFlowを使った深層学習モデルの開発と、それらを使ってAmazon Web Services (AWS)にデプロイできるAPIやバッチアプリケーションの開発です。

CI/CDとは

Continuous Integration (CI)

Continuous Integrationとは、開発者が行った変更をソースリポジトリのメインブランチに可能な限り頻繁にマージすることです。

これにより、ソースコードを結合する時間が短縮され、リリース前に他の開発者のアプリケーションの変更をマージすることで発生する問題を軽減することができます。

開発者がコードをメインブランチにマージするたびに、自動ユニットテストや統合テストが実行され、自動的にテストされます。

Continuous Delivery/Deployment (CD)

Continuous Delivery/Deploymentとは、アプリケーションの変更をテスト環境や本番環境に自動的にデプロイするプロセスです。

このプロセスのすべてのステップが完全に自動化され、人の介入を必要としないのが理想です。

ただ、CI/CDの導入する前に下記の導入も重要だと考えています。

●新機能を別々のブランチで開発し、リリースのためにメインブランチにマージするワークフローです。
●ビルドおよびデプロイメントパイプラインのさまざまな段階で実行可能な自動テストです。
●クラウドサービスを使用している場合、アプリケーションが実行されるインフラが自動的に立ち上がる方法です。
●インフラにアプリケーションを自動的にデプロイする方法です。
●新しいカラムの追加や参照データの挿入など、データベースの変更を管理するための自動化されたプロセスが存在することも理想的です。

CI/CDに向けたAWSサービス

AWSでは、CI/CDパイプラインを実装するための様々なサービスが提供されています。以下に主なサービスを紹介します。

AWS CodeCommit

CodeCommit は、AWSにホストされているGitリポジトリです。GitHubのようなサービスです。

AWS CodeBuild

CodeBuild は、ソースコードをコンパイル・ビルド・テストできるAWSのサービスです。

AWS CodeDeploy

CodeDeploy は、CloudFormation、ECSとLambdaに向けたデプロイメントのサービスです。Blue/Green デプロイなど機能を提供しています。

AWS CodePipeline

CodePipeline は、ビルドとデプロイのプロセスの全体的なフローを定義します。

CI/CDフローの実装

先に紹介したAWSサービスを使ってCI/CDのフローを実装します。

プロジェクトの要件に応じて必要なステップと技術が異なる場合もあると思いますが、CI/CDのフローは最低限でも下記に載っているステップが必要だと思います。

１，開発者は、ソースコードをCodeCommitにpushします。
２，CodePipelineは、CodeCommitのソースコードが更新されたたびに、最新のソースコードを取得します。
３，CodePipelineは、CodeBuildにソースコードを渡します。CodeBuildは、ソースコードをテスト・パッケージし、ECRにアップロードし、タグを付けます。アップロードしたイメージのURIをアウトプットします。
４，CodeCommitにあったCloudFormationテンプレートを実行します。最新のイメージをデプロイするために、CodeBuildで作成したイメージのURIにCloudFormationテンプレートのURIパラメーターを書き換えます。CloudFormationで開発環境のリソースをデプロイします。
５，承認を得るまで待ちます。
６，承認された場合、ステップ４と同じように本番環境のリソースをデプロイします。

サンプルコードには含まれていませんが、以下のタスクをフローに追加することを強く勧めます。

●自動ユニット・インテグレーションテストの追加
●デプロイ後、APIへの自動システムテストの追加
●Gitにビルドに使ってたソースコードにタグを付けます
●コード静的分析、コードカバレッジのレポート生成

これらのタスクのどれかが失敗したり、コードが一定の品質レベルを満たしていない場合、ビルドは停止します。

CodePipelineの構築

このフローを実現するために、フローのステップをCloudFormationのテンプレートで定義します。

CloudFormationのテンプレートでCI/CDフローに必要なAWSリソースを見てみましょう。

ユーザーが入力可能なパラメータ

ユーザーが入力可能なパラメータを定義しましょう。このような情報をパラメータとしてテンプレートに入れることで、テンプレートを変更することなく、他のプロジェクトで再利用することができます。

ほとんどのリソース名をApplicationName (アプリケーション名)のパラメータに基づいて決定します。また、ソースコードを取得したいブランチや、DockerイメージをアップロードしたいECRリポジトリの名前を指定できるようにします。

AWSTemplateFormatVersion: 2010-09-09
Parameters:
  ApplicationName:
    Default: SampleApi
    Type: String
    Description: Enter the name of your application
  CodeBuildImage:
    Default: 'aws/codebuild/standard:4.0'
    Type: String
    Description: Name of codebuild image to use.
  BranchName:
    Description: 'The name of the branch to deploy from.'
    Type: String
    Default: 'main'
  ImageRepository:
    Description: 'The name of the ECR repository where images are stored.'
    Type: String
    Default: 'test'

CodeCommitリポジトリ作成

ユーザーが入力したApplicationNameの元にリポジトリの名前を設定し、作成します。

SourceRepository:
 Type: 'AWS::CodeCommit::Repository'
 Properties:
   RepositoryName: !Ref ApplicationName
   RepositoryDescription: !Sub 'Source code for ${ApplicationName}'

CodeBuildのジョブ

Dockerイメージをビルドし、ECRにアップロードするためにCodeBuildのプロジェクトを作成します。

こちらに設定された環境変数はビルドのコンテナ内でアクセスできます。

AppPackageBuild:
 Type: 'AWS::CodeBuild::Project'
 Properties:
   Artifacts:
     Type: CODEPIPELINE
   Environment:
     ComputeType: BUILD_GENERAL1_SMALL
     Image: !Ref CodeBuildImage
     Type: LINUX_CONTAINER
     PrivilegedMode: True
     EnvironmentVariables:
       - Name: REPOSITORY_NAME
         Value: !Ref ImageRepository
       - Name: AWS_DEFAULT_REGION
         Value: !Sub '${AWS::Region}'
       - Name: AWS_ACCOUNT_ID
         Value: !Sub '${AWS::AccountId}'
   Name: !Sub '${ApplicationName}Build'
   ServiceRole: !GetAtt
     - CodeBuildRole
     - Arn
   Source:
     Type: CODEPIPELINE

buildspec.yaml

デフォルトでは、CodeBuildのプロジェクトは、buildspec.yamlというファイルの中のコマンドを実行して、アプリケーションをパッケージします。このファイルの内容を説明します。

version: 0.2
phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws --version
      - ECR_URL=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
      - REPOSITORY_URI=$ECR_URL/$REPOSITORY_NAME
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_URL
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - BUILD_TAG=$(echo $CODEBUILD_BUILD_ID | awk -F":" '{print $2}')
      - BUILD_LABEL=build-$BUILD_TAG

ビルドの事前準備です。ECRのリポジトリにログインし、ビルドの番号を作成します。次のステップにこれを使う予定です。

  build:
    commands:
      - echo Build started on `date`
      - echo Building the Docker image...
      - docker build -f Dockerfile.lambda -t $REPOSITORY_URI:latest .
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$BUILD_LABEL
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$COMMIT_HASH
      - printf '{"ImageUri":"%s"}' $REPOSITORY_URI:$BUILD_LABEL > image.json
      - cp deploy/lambda.yaml deploy.yaml

buildspec.yamlの主要部分です。Dockerのイメージにソースコードをパッケージします。イメージにバージョンのタグを付けます。最後にイメージURIをファイルにアウトプットします。

  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker images...
      - docker push $REPOSITORY_URI:latest
      - docker push $REPOSITORY_URI:$BUILD_LABEL
      - docker push $REPOSITORY_URI:$COMMIT_HASH
artifacts:
  files:
    - image.json
    - deploy.yaml

ビルド後の処理です。DockerのイメージをECRにアップロードします。CodePipelineでの次のステップに利用するファイルをartifactsに指定します。

CodePipeline

こちらからCodePipelineのフローを定義します。まずは、CodePipelineの名前と必要なRoleを設定します。

  AppPipeline:
    Type: 'AWS::CodePipeline::Pipeline'
    Properties:
      Name: !Sub '${ApplicationName}Pipeline'
      ArtifactStore:
        Type: S3
        Location: !Ref ArtifactBucketStore
      RoleArn: !GetAtt
        - CodePipelineRole
        - Arn

StagesのところにCodePipelineのステップを定義します。

最初のステップは、CodeCommitからソースコードを取得するステップです。

      Stages:
        - Name: Source
          Actions:
            - ActionTypeId:
                Category: Source
                Owner: AWS
                Version: 1
                Provider: CodeCommit
              Configuration:
                BranchName: !Ref BranchName
                RepositoryName: !GetAtt
                  - SourceRepository
                  - Name
              OutputArtifacts:
                - Name: SourceRepo
              RunOrder: 1
              Name: Source            

その次のステップは、以前に定義されたCodeBuildのプロジェクトを参照し、ソースコードをビルドするステップです。

CodeBuildがビルドした成果物（DockerイメージのURIとCloudFormationのテンプレート）がBuildArtefactsに保存されています。それは次のステップに参照できます。

        - Name: Build
          Actions:
            - InputArtifacts:
                - Name: SourceRepo
              Name: CodeBuild
              ActionTypeId:
                Category: Build
                Owner: AWS
                Version: 1
                Provider: CodeBuild
              OutputArtifacts:
                - Name: BuildArtefacts
              Configuration:
                ProjectName: !Ref AppPackageBuild
              RunOrder: 1

CloudFormationのテンプレートで開発環境デプロイに向けた変更セット(Change Set)を作成します。

変更セット(Change Set)では、テンプレートが実際に実行される前に、どのリソースが作成、変更、削除されるかを確認することができます。

デプロイする前に先ほどECRにアップロードしたDockerイメージのURIをCloudFormationのテンプレートに書き換えます。デプロイするテンプレートのパスは、BuildArtefactsに保存したCloudFormationのテンプレートに設定します。

        - Name: Development
          Actions:
            - ActionTypeId:
                Category: Deploy
                Owner: AWS
                Version: 1
                Provider: CloudFormation
              InputArtifacts:
                - Name: BuildArtefacts
              Name: CreateDevelopmentChangeSet
              Configuration:
                ActionMode: CHANGE_SET_REPLACE
                ChangeSetName: !Sub '${ApplicationName}DevelopmentChangeSet'
                RoleArn: !GetAtt
                  - CFNDeployRole
                  - Arn
                Capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND
                StackName: !Sub '${ApplicationName}DevelopmentStack'
                TemplatePath: 'BuildArtefacts::deploy.yaml'
                ParameterOverrides: |
                  {
                    "ImageUri": {"Fn::GetParam": ["BuildArtefacts", "image.json", "ImageUri"]}
                  }
              RunOrder: 1

次に、前のステップで作成した変更セットを実行し、実際に開発環境へのデプロイを行います。

            - RunOrder: 2
              ActionTypeId:
                Category: Deploy
                Owner: AWS
                Version: 1
                Provider: CloudFormation
              Configuration:
                StackName: !Sub '${ApplicationName}DevelopmentStack'
                ActionMode: CHANGE_SET_EXECUTE
                ChangeSetName: !Sub '${ApplicationName}DevelopmentChangeSet'
                OutputFileName: StackOutputs.json
              Name: ExecuteChangeSet
              OutputArtifacts:
                - Name: AppDeploymentValuesDevelopment

開発環境へのデプロイが完了したら、次は本番環境に同じパッケージしたイメージをデプロイします。

開発環境のように変更セットを作成し、DockerイメージのURIをCloudFormationのテンプレートに書き換えます。

        - Name: Production
          Actions:
            - ActionTypeId:
                Category: Deploy
                Owner: AWS
                Version: 1
                Provider: CloudFormation
              InputArtifacts:
                - Name: BuildArtefacts
              Name: CreateProductionChangeSet
              Configuration:
                ActionMode: CHANGE_SET_REPLACE
                ChangeSetName: !Sub '${ApplicationName}ProductionChangeSet'
                RoleArn: !GetAtt
                  - CFNDeployRole
                  - Arn
                Capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND
                StackName: !Sub '${ApplicationName}ProductionStack'
                TemplatePath: 'BuildArtefacts::deploy.yaml'
                ParameterOverrides: |
                  {
                    "ImageUri": {"Fn::GetParam": ["BuildArtefacts", "image.json", "ImageUri"]}
                  }
              RunOrder: 1

本番デプロイが行われる前に、チームリーダーなどの承認が得られるまでデプロイを停止する承認ステップを追加します。 このステップでは、変更セットが実際に実行される前に変更セットの詳細を確認することができます。

            - Name: DeploymentApproval
              ActionTypeId:
                Category: Approval
                Owner: AWS
                Version: 1
                Provider: Manual
              Configuration:
                NotificationArn: !Ref ApprovalTopic
                CustomData: 'Please approve the change set to allow deployment.'
              RunOrder: 2

最後のステップでは、実際に本番環境にデプロイを行ないます。

            - Name: ExecuteChangeSet
              ActionTypeId:
                Category: Deploy
                Owner: AWS
                Version: 1
                Provider: CloudFormation
              Configuration:
                StackName: !Sub '${ApplicationName}ProductionStack'
                ActionMode: CHANGE_SET_EXECUTE
                ChangeSetName: !Sub '${ApplicationName}ProductionChangeSet'
                OutputFileName: StackOutputs.json
              OutputArtifacts:
                - Name: AppDeploymentValuesProduction
              RunOrder: 3

テンプレートの残りの部分は、CodePipelineとCodeBuildのプロジェクトに権限を付与する周りです。

こちらにテンプレート全体を確認してください

Code Pipelineのデプロイ

先に定義したCode Pipelineのテンプレートを実行するには、以下の手順を行います。

１，CloudFormationのコンソールを開きます 。
２，利用したいリージョンを選択します。
３，Create Stack With new resources (standard) 「スタックの作成 (新しいリソース)」を選択します。
４，テンプレートファイルのアップロードを選択します。
５，deploy/pipeline.yamlのパスを入力します。(Next)「次へ」をクリックします。
６，テンプレートに必要なパラメータを入力します。
１，Stack Name。 今から作成するスタックの名前です。例：「ImageNetPipeline」。
２，ApplicationName。アプリケーションの名前です。多くのCodePipelineに入っているリソースはこの名前の元に作る予定です。
３，BranchName。どのブランチからソースコードを習得します。
４，ImageRepository。ECRのリポジトリの名前です。
７，(Next) 「次へ」をクリックします。
８，画面下部のチェックボックスをすべてチェックします。
９，(Create Stack)「スタック作成」をクリックします。

初めてのビルドとデプロイ

テンプレートのデプロイ後、CodeCommitリポジトリにコードが存在しないため、Code Pipelineは失敗状態になります。

ソースコードをpushすると、Code Pipelineのビルドが自動的に始まります。

ビルドが無事に完了するとCloudFormationで開発環境を立ち上がってDockerのイメージをデプロイします。

その後、本番環境へのデプロイのステップに入り、ビルドは停止し、承認が得られるのを待ちます。

リリースが承認されると、ビルドが続行され、本番環境へのデプロイも完了します。

最後に

この記事では、AWSのCI/CDに向けたサービスを使い、自動ビルドとデプロイのフローを実現できました。

このパイプラインは出発点として使用されるべきで、プロジェクトの要件に合わせてステップの追加や削除、フローの変更を自由に行うことができます。

ソースファイル

このプログ記事で使ったソースファイルをGitHubに公開しました。

●buildspec.yaml – CodeBuildが利用されたbuildspec.yamlファイル
●Dockerfile.lambda – Lambdaのデプロイに向けたDockerfile
●deploy/lambda.yaml – Lambdaのデプロイに向けたCloudFormationのテンプレート
●deploy/pipeline.yaml – CodePipelineのデプロイに向けたCloudFormationのテンプレート

最後までお読みいただき、ありがとうございました。

自己紹介

こんにちは。

沖縄に拠点を構える株式会社プロトソリューションで、インハウスマーケターをしているフクハラです。 オウンドメディアのSEOを中心にWeb集客支援の領域を担当しています。

はじめに

Webマーケティングを行う上で、避けては通れないアクセス解析。 今回はそのアクセス解析に欠かせない二つのツール『Google Analytics（以下GA）』と『Search Console（以下サチコ）』の違いを簡潔にまとめてみました。 Web担当者になったら知っておきたい基本中の基本が、サクッと読んでパッと理解できる内容です。

【こんな人におススメ】
・自分で調べたが理解できなかった人
・長文を読む時間の確保が難しい人

そもそも「Google Analyticsって何！？」「Search Consoleとは何ぞ！？」と、なっている人は丁寧に説明しているサイトが星の数程存在しているので、そちらを参考にしてください。

GAってなに？

●GA（グーグルアナリティクス）：

簡単にまとめると、

Webサイト上でのユーザー行動を数値化したものです。

ユーザーの行動履歴で「どんな人」が「どんなデバイス」を使って「どうやって訪問」してきたのか、そしてサイトのどこに魅力や不満を感じたのか、サイトへ訪問した目的は達成したのか？していないのか？などを知る事ができます。

代表的な指標：ユニークユーザー数、セッション数、ページビュー数

サチコってなに？

●サチコ（サーチコンソール）：

簡単にまとめると、

グーグルから見た自社サイトの状況を数値化したものです。

グーグルの検索結果ページ（SERPs）でのパフォーマンスで、対象ページがどんなクエリで何位に掲載されていて、何回表示されていて、何回クリックされたのか、などなどが把握できます。

代表的な指標：クリック数、表示回数、CTR、掲載順位

GAとサチコの違い（データ編）

取扱いデータを簡潔に説明すると、 Webサイトを軸にユーザーの状態（Webサイトへ訪問する前後）で区別しているデータと言えます。

●GA（グーグルアナリティクス）：Webサイトへ訪問した後のデータ

●サチコ（サーチコンソール）：Webサイトへ訪問する前のデータ

GAとサチコの違い（利用編）

何をいつどう利用するのか、
それは前述したユーザーの状態によって決められます。
簡潔にまとめると、以下のようになります。

●GA（グーグルアナリティクス）：

GAは、Webサイトの目的（コンバージョン）を達成させたい時に、 訪問ユーザーの行動（直帰率や滞在時間など）や閲覧状況を把握して、データ分析を行い改善に向けて利用します。

●サチコ（サーチコンソール）：

サチコは、Webサイトへの訪問ユーザー（集客）を増加させたい時に、 掲載順位・表示回数・クリック数・CTRを基に強化するクエリやページを把握して、データ分析を行い改善に向けて利用します。

まとめ

つまり、

●GA（グーグルアナリティクス）とは、ユーザーの行動履歴を基に、CVの最適化を行う為のツール

●サチコ（サーチコンソール）とは、グーグルのパフォーマンス評価を基に、集客の最適化を行う為のツール

と言えるでしょう。

したがって、改善したいポイントが「CV（コンバージョン）」なのか「集客」なのかでツールが選択できます。

本来はどちらのツールももっと深く、もっと細かく分析ができますが、個人的に一番押さえておくべきだと思っている事を3分で理解できるようにまとめてみました。

いかがでしたでしょうか。

今回ご興味を持っていただけたようでしたら、ぜひいろんな視点からデータ分析にチャレンジしてみてください。

それでは、お疲れ様でした。

はじめに

このブログでは、情報処理の単位を落とすほどITに疎く、大抵の問題は「気力と体力」で解決してきた男が、「これからの時代はスマートフォンか！」と無謀にもIT業界に飛び込み、
8年間の経験を通して感じたエンジニアに必要なスキルについて、ご紹介できればと思います。
「システム開発ってどんなんなん？」と考えている方や、実際に開発現場で働く人にも、何かヒントになるお話しができれば幸いです。

自己紹介

こんにちは、はじめまして。プロトソリューションの棚原と申します。
私はAIテクノロジー推進室沖縄に所属しており、現在は自社SaaS開発の業務に携わっています。
​
私は入社してこれまで、Webアプリやスマートフォンアプリの開発、ハイブリットアプリやAPIの開発と、さまざまなプロジェクトでさまざまなシステム開発に携わってきました。
経歴を簡単にまとめると以下の通りです。

私の考えるエンジニアのスキル

これらの経験を通して私が考えるエンジニアに必要なスキルは、「効率的により速く、最適解を導き出す」力だと考えます。 システム開発とは、「業務上発生する何かしらの課題をコンピューターの力で自動化・効率化・仕組み化する」様な仕事をしますが、その中で効率的により速く最適な答えを出すことがなぜ必要だと考えるのか、説明していきたいと思います。

なぜ「効率的により速く」が必要か？

私たちの仕事はどのプロジェクトにおいても、背景にビジネスがあり、ニーズがあり、競合がいて、必ず期限があります。 こうした背景の中にある課題を技術で解決することがエンジニアには求められますし、そこにはスピードが伴います。それに応え、効率よく素早く課題を解決することがエンジニアの仕事なんだと、私は考えています。

どうやって「効率的により速く」を実現するか？

例えば、ドラえもんはポケットの中から課題に対する最適な答えを素早く出し、課題を解決します。まさに理想像です。 ですが、ドラえもんのすごいところは、道具を的確に出すところです。 つまり、多くの引き出しを持ち、それらでどんなことができるかを知ってるということが、効率的により速く答えを導き出すスキルの一つなんだと思います。

私も色々な技術に触れたことで、それぞれのクセや特徴が引き出しになり、ふとした場面で課題解決のヒントとなった経験が多々あります。

また、多くの引き出しを持つというのは「知ってるだけ」で十分です。 極端な話ですが、私は未だにプログラミングの基本構文であるfor文も覚えていません。知ってるだけです。それでもIDE（プログラミング環境）の拡張機能を使ってfor文を書くことができます。 無駄に多くのことは覚えず、必要な時に取り出せればとても効率的です。

知ってるか知らないかの違い

少しかじった話になりますが、具体例でイメージしていきます。 例えば、Webサイト（静的サイト）を作成してインターネットに公開したい、という場面があります。

Webサーバを利用した場合

通常、Webサイトを構築・公開するには、大きく以下の様な対応が必要になります。

・Webページの制作
・Webサーバの構築（サーバの調達・ミドルウェア（Webサーバソフトウェア）のインストール等）
・Webページのアップロード・公開
・サーバの運用監視

と手間がかかります。

Amazon S3を利用した場合

ところが、AWS（Amazon Web Services）のS3というストレージサービスの静的ウェブサイトホスティングを利用した場合はこうなります。

・Webページの制作
・S3バケットの作成・設定
・Webページのアップロード・公開

S3を利用すればWebサーバの構築が不要で、必要な設定は管理画面上で操作でき比較的容易です。 また、S3はマネージドサービスでサーバの運用監視が不要です。（しかも安価です）

AWS Amplifyを利用した場合

それだけでなく、同じくAWSのAmplifyというサービスを利用した場合、S3の静的ホスティングと同様の仕組みを自動で構築してくれる他、https通信に対応させる為のSSL証明書の発行・設定も自動で行われたり、カスタムドメインの設定が管理画面上で容易にできたりと、手動で行う作業を更に削減することができます。

このケースだと、Amplifyで出来ることや特徴を知っていることで、他の構成よりも効率的により速くWebサイトを構築することができます。

実際の現場では、どの構成が最適なのかはプロジェクトの要件次第です。 ですが、複数の構成パターンを知っていることで、効率的でリソースに無駄のない最適な選択ができます。

プログラミングにおいての効率

上の例はシステム構成寄りのお話でしたが、プログラミングの場面でも「知ってるかどうか」が効率化につながります。

複雑さがないこと・無駄なプログラムは書かないこと

身近なExcelの関数で簡単な例です。

①
=IF(A1>=80, "優", IF(A1>=70, "良", IF(A1>=60, "可", "不可"))) 

②
=IFS(A1>=80, "優", A1>=70, "良", A1>=60, "可", A1<60, "不可")

どちらも同じ結果を得られますが、①の方は入れ子が多く見辛いです。条件が増えると更に見づらくなります。 ②のIFS関数を知っていれば、シンプルになります。 プログラミングでも、プログラムが見辛いと不具合につながりますし、シンプルである方がレビューなど多方面に効率的です。

引き出しから引き出しが生まれる

また専門的な話になってしまいますが、プログラミングでの例です。 プログラミング言語は、それぞれ似た様な機能を持つことがあります。

Javaで有名なエラーにぬるぽ（NullPointerException）があります。 nullの格納された変数に、メソッド呼び出し等すると発生します。発生するとアプリが停止したり、致命的です。

String str; // null

int num = str.length(); // ぬるぽ

Swiftでも同様のエラーがありますが、これを避ける方法としてOptional Chainingという機能が用意されています。

var str: String? // nil

let num = str?.count() //Optional Chaining

JavaScriptでも同様のエラーを避けたい場合があります。 そうした場合、「JavaScript Optional Chaining」とググってみます。

var str //undefined

let num = str?.length //Optional Chaining

JavaScriptでも同じくOptional Chainingが用意されていることがわかり、同じ様な記述で回避できました。 この様に、一つの言語で知っていた情報が、他の言語においても解決策となる場合があり、その観点さえあれば、効率的に問題を解決することができます。

まとめ

いかがでしたでしょうか。 ここで私がお話ししたかった内容をまとめるとこの様になります。

・システム開発とは、様々な背景にある課題を解決する仕事であること
・システムの設計やプログラミングは課題解決の手段で、それを駆使して課題を解決するのがエンジニアであること
・課題解決の手段はより多くより効率的である方が、最適で素早い課題の解決につながること

これはもちろん、基礎があってこそだと思います。 私自身もPHP, Objective-Cのプログラミング学習から始まり、色々なプロジェクトに首を突っ込むことで Webアプリ→API、iOSアプリ→Androidアプリ→ハイブリットアプリ→SPAと引き出しや感覚を身につけてきました。 これを機会に、この経験談が誰かのスキルアップに繋がれば大変嬉しく思います。

おわりに

今なら情報処理で”優”が取れそうな、なんかそんな気がしました。 今回は技術特化の内容ではありませんでしたが、またの機会には日頃触れている技術のアウトプットもしていきたいと思います。 最後までご覧いただきありがとうございました。