AWS CodePipeLineに初めて触った時のメモ
先週初めてCodePipeLineを使ってみました
その時のメモを残しておきます。
前提
- CodeCommitにコミットができる状態であること
- CodeBuildで手動ビルドができる状態であること
CodePipeLineとは？
CodePipeLineはAWSのCI／CDサービスです。
各フェーズごとにステージを作成することができ、
さらにステージ内で行う行動をアクションで定義することができます。
例えば、コミットステージにCodeCommitのプッシュをトリガーとして初め、そこの成果物を元にビルドステージでアクションとしてCodeBuildのビルドやテストを行う、と言ったことを直感的に作れることができます。
また、AWSサービス以外にもGitHubやCIサーバーなどサードパーティーの連携などもできるようです。
今回は第一歩目として、設定しやすいAWSのサービス内のみを使用して実現しました。
行なったこと
今回はUdemyのとある学習教材を元に、パイプラインの設定をしていきました。
この手順を以下に記載します。
まず、CodePipelineを開き、「パイプラインを作成する」ボタンを押します。
押した後の画面が下記になります。
パイプライン名は任意、そのほかはデフォルトで設定します。
設定が終わったら「次に」押します。
この段階はソースステージ、CICDを行いたいリポジトリを選択できます。
サードパーティのリポジトリホスティングサービスも利用できますが、ここではCodeCommitを選択します。
CodeCommitの場合、リポジトリ名とブランチ名を検索できるので設定はかなり簡単でした。
そのほかの設定はデフォルトのままで「次に」を押します。
このページはビルドステージの追加を行うことができます。
ビルドステージではJenkinsやCircleCIなどのサードパーティのビルドサーバーやCodeBuildを選択できます。
CodeBuildの場合はソースステージで選択したリポジトリのルートにBuildspec.ymlを配置することで 記載に沿ったコマンドを実行することができます。
設定としてはあらかじめCodeBuildでビルドプロジェクトを作成していれば、プロパイダーとリージョンを指定した上でプロジェクトを選択することができます。（その場で作成することもできるようです）
経験上、かなり複雑な場合もありますのでスキップして後で追加することもできます。
自分の場合は別のチュートリアルですでにビルドプロジェクトを作成していたのでそちらを指定して「次に」を押して進みました。
デプロイステージではビルドしたものをどこにデプロイするか設定することができます。
写真ではElasticBeanStalkを指定していますが、ECSだったりS3だったり、CodeDeployだったりを指定できますが、実はCacaponはこの辺りの知見はまだありません、今後要勉強ですね。
スキップすることもできますので、わからなかったらスキップしましょう。
次が最後のページです。
確認が終わりましたら「パイプラインを作成をする」を押すと、一連のサービスが繋がった状態になります。
つまり、CodeCommitにコミットすると、CodeBuildでビルド・テストされ、正常だった場合はElasticBeanStalkにデプロイされるというフローが自動的に実行されるのです。
これで来たとき冗談抜きですげーって言っちゃいました笑
ちなみに、本番環境のデプロイなどで人間の確認が必要な場合は手動承認などのアクションもステージの中の一つのアクションとして定義することができます。SNS経由で承認者にメールを送ることもできるので、よりよいCI/CDが実現できそうですね。
課題
ここまでチュートリアルに沿って作成しましたが、何点か課題も残っています。こちらに関しては後日まとめられたらなと考えております。
CodeBuildのbuildspec.ymlの書き方がわからない
CodeBuildはルートに置かれたbuildspec.ymlに沿ってビルド作業を行います。
固有の書き方なので書いて行ったら覚えられるでしょうが、自在に描けるようになりたいですね。
CodeDeploy周りがあまりわかっていない。
できることといえば、どこにデプロイするかを決められるみたいなのですがまだ覚えられていないので要勉強です
権限まわりをどう設定するか
今回はAdmin権限で行なってしまったので、設定するのにどんな権限が必要なのか理解しておりません。
仕事ではAdmin権限などもらえませんし、現場で自力で作る時は出てくると思うので、
何の権限が必要なのかを相手に伝えるためにもちゃんと勉強したいところですね
クロスアカウントアクセスの場合の挙動の理解
早速仕事場でも自動化を進めようと思い利用してみたのですが、初回でコミットの権限がないエラーが発生してしまいました。
そちらはクロスアカウントでアクセスする形式だったのですが、この場合の挙動などはあまりわかっておりません。
ちなみに、コミットでトリガーで動いた場合は特に問題ありませんでした、なんだったのだろう。
サードパーティを絡めた場合の挙動
どれくらいめんどくさくなるのか？それともかなり簡単に作れるのか？
GithubやJenkinsを使っている人もいるでしょうしこの辺りは一通りやって理解したいですね。
という感じで、CodePipeLineをやってみた時のメモでした。
想像以上にコミットとビルドは設定できるので、CI/CDのとっかかりとしてはかなりおすすめです。
このメモが参考になりましたら幸いです、また次回のブログでお会いしましょう。
関数型的にプログラムを書くとテストがしやすいなという話
私は中途半端に関数型言語を学んでいるところなのですが、それでもオブジェクト型言語とは異なるメリットを感じることがよくあります。
今日はその中の一つとして、「関数型言語で関数を作るとテストが作りやすい」という話をしていこうと思います。
なぜテストが作りやすいの？
関数型言語で関数を作る場合、基本的に以下の形に収まります。
単数、もしくは複数の入力を受け付けて一つのアウトプットを出す、と言った形ですね。
オブジェクト型の言語だとprint()みたいに値を返さない関数とかかなりあると思うのですが、
関数型は基本的にvoid型はあまり使わなそうな印象です*1
この形だとどのようなメリットがあるかというと「InputがXだった時、OutputがYになる」という動きになり、テスト用のXと出力結果Yを比較する値さえ用意できれば、関数Fxのテストができるようになるメリットがあります。
例えば、f(x) = x * 2 をテストしたい場合はf(2)の時4になるかをチェックすればテストできます。
注意！ 入力が同じなら出力も同じ関数でないとテストできない
ただ、関数を作る際、注意があります。「InputがXだった時、Outputが必ずYになる」ということを保証できる関数である必要があります。このようにしないとテストがしにくい関数になってしまいます。
例えをみてみましょう。
ある場所Xを入力すると今日の天気を出力する関数を作りました。
この関数は、前述の関数の基本的な形に当てはまる構成をしております。が、テストは非常にしにくい関数です。
なぜなら実行するタイミングで出力が変わってしまうからです。
今ブログを書いている時点で私の現在地で関数を実行したら「晴れ」と返すでしょう。
では、何日か後に同じ関数を実行したらどうなるでしょうか？
同じく「晴れ」を返すかもしれませんが、「くもり」かもしれませんし、「雪」だったり「雨」かもしれません。
このように同じ関数でも結果が変わってしまうと、出力のチェックができなくなります。
そうするとテストをしようにも「何かしら値が返ってきてる」とか「晴れ、曇り、雨、雪のいずれかが返ってくる」と言った大雑把なテストになって、何をテストしてるかわからないテストになりがちです。
このような関数をテストしやすくする場合は、場合によって変わる部分を切り出して入力にするとテストできるようになったりします。
例えば、前述天気関数でしたら、時刻を新しい入力にすれば、テストのできる関数になります。
本日はここまで、またお会いしましょう。
*1:勉強で使用している本ではREPL形式で実行されるためか、勝手に変数がアウトプットされているような形でした。標準出力をどのように行うのかは今後勉強を進める上で調べてみようと思います
新しくAWSの資格の勉強を始めました。
前回AWSソリューションアーキテクトアソシエイトの資格を合格したCacaponですが、
他の資格も興味を持ち始めまして、現在Developerアソシエイトの資格を勉強中です。
まだ学び始めたばかりですが、開発よりの使い方を学べているので実務に活かせそうな実感があります。
1ヶ月勉強したら試験に受けてみようと思います。
今日はこの辺で、それではまた会いましょう。
リモート業務の方向け、足の冷えを解消する方法7選
最近足の冷えが気になるCacaponです。
リモート作業で座りっぱなしだとどんどん冷えて仕事の効率が下がってくるのですよね…
そんなわけで、個人的に試している、足の冷えを解消する方法をまとめてみました。
その１ 湯たんぽ
湯たんぽに熱湯を入れて足に当てて過ごしています。
半日くらいは持つので、１回入れ替えて使えば大体あったかく過ごせますね。
その２ 散歩
５〜１０分くらい歩けば大体温まります。
晴れている時なんかは気分転換にもGood
その３ 竹足踏み
雨が降っている時なんかは散歩できないので、以前買った足踏み用の竹をふみふみしながら。
これも５分くらいやっていると程よく足がポカポカします。
その４ フルスクワット
完全にしゃがみ込むスクワットだとふくらはぎも使いますので、１０回やるだけでも結構足の血流が良くなったりします。
ただ、結構負荷は強いので、普段トレーニングしていない人は注意
その５ マッサージ
昔取った杵柄でオイルマッサージの要領で足・ふくらはぎ・すね・膝裏などを中心に揉んだり指圧したりしてほぐします。硬さが気になるところを重点的にほぐすだけでも足が軽くなる感じはあります。
その６ 足湯
多少準備が要りますが、足湯も体を温めるのに効果的だと思います。
足をつけているだけで血流が良くなりますが、湯冷めしないように注意
その７ つま先で足の曲げ伸ばし
よく冷え性対策で検索すると出てくる運動。
ふくらはぎを動かすので血流は良くなるのですが、個人的には散歩とか足踏みの方が好き。
以上になります、足の冷えが気になる方で何かできそうなことがあったらぜひ試してみてください。
それではまた。
テストピラミッドの考え方についてのメモ
テストピラミッドという考え方を知りました。
UIテスト
と階層になっていて、
下に行くに連れて比重を多くするのが理想だそうです。
また、確認したい範囲がテスト毎に異なっていること、テスターさんはUIテストに比重を置きがちになって、ビルドやテスト時間が伸びてしまってる問題にぶつかる事も知りました。
ビルド時間が長くなると段々とやらなくなってしまうので、テストピラミッドを意識したテスト構成を作成する事を心がけようと思います。
本日はここまで、またお会いしましょう。
自動化について考えてみる
自動化に必要そうなアイデアを箇条書きでまとめてみます。
- ローカルでもグローバルでもバージョン管理を行うこと
- ローカルでコミットする前に、自動でユニットテストを行うようにしておく
- ユニットテストが通らないなら、コミット出来ないようにする
- gitの場合はgit-hookのpre-commitで実装可能
- shellで実行できることなら他にもできるので、lintなどにも使える
- バージョン管理サービスにプッシュされたのをトリガーとしてビルドサービスを行う
- ビルドサービスはAWS CodeBuildくらいしかよく分かっていない。
- ビルドして、アーティファクトをダウンロードできる状態にするサービスは何がある？
- できたアーティファクトをデプロイするサービスを使う
- 例えばスマフォならDeploygateなどに送る、Google Playに送るなど？
- サーバーレスアプリならLambdaにデプロイやコンテナのアップロードなど
- この辺の動きもよく分かっていない。
- 途中で失敗したらチャットツールなどに送信する機能を使う
- ビルドが失敗した時にすぐわかる
ここまで書いてみて、コミットあたりまではある程度知見があるのですが
その後の連携はあやしそうなので、もう少し勉強しようと思います。
各サービスの連携とかを自分で作れるようになりたいですね😄
