Goのパッケージ構成の失敗遍歴と現状確認
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
TDD of Infrastructure as Code on CircleCI 2.0
概要Docker + Ansible + ServerSpec + CircleCI 2.0でTDDなCIビルドを行う話です。 今僕が在籍している企業では、プロビジョニング周りはAWS OpsWorksで管理されており、Chefのカスタマイズレシピが適用されて、ポンっと環境が構築されます。 個人的にはChefとItamaeの運用はしたことがありますが、OpsWorksを除けばAnsibleの方がStar数も多く活発に使われていそうなのと、どうせならDockerとServerSpecを使ってポータブルなテスト環境を作ってみよう、それをCircleCI2.0で効率的に回そう、と思い立って、やってみました。 ディレクトリ構成. ├── Dockerfile ├── README.md ├── ansible │ ├── ansible.cfg │ ├── ci.yml │ ├── circlec
CircleCI2.0でのGolang APIのデプロイ設定
今在籍している企業では、最近CircleCI2.0へのアップグレードが盛んに行われている。 すでにアップグレードを体験された方からは、「は？」「速すぎてドン引き」「爆速すぎてずっと泣いてる」などとの感想が寄せられている。元気そう。 具体的に自分もAPIでバージョンを上げたら、6分半が45秒になった。 で、特定のpackageのtestだったり、インフラ周りの設定のアタッチ等なら小規模なのでなんとなくかけば導入できる。 しかしAPIとなると、意外と設定を載せているところがまだ少なかったので、API用途だとざっくりとこんな感じだよというのを書きたいと思う。 もしそこまでじゃなくていいので、簡単な設定がみたければこちらへどうぞ 全体感APIやある程度の規模のソフトウェアのCIとなると、 依存パッケージのインストールlinterでの文法チェックテストデプロイの諸々をやらなくてはならない。 色々名前
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
