なるべくお金をかけずに個人アプリを運用したい - くりにっき
前々からこの手のことを書きたいとは思ってたけど id:k0kubun さんの下記エントリに触発されて書きました。 k0kubun.hatenablog.com tl;dr; 個人アプリ開発歴 前提 Heroku GCP Google App Engine Cloud Run Firebase Cloud Functions GitHub Pages 2022/8/14追記 GitLab Pages 2022/5/7 17:00追記：ブコメレス tl;dr; HerokuやFirebaseを駆使すれば割と無料でいける 若干お金を払えばもっと選択肢は増える 個人アプリ開発歴 2001～2002年あたりから個人HPでアプリを公開。後にVectorにも公開 アカウントは残ってるのでいまだにVectorからのレポートメールが毎月届いてます 2009年くらいから色々ウェブアプリを開発 Google A
GitHub-native DependabotでもAuto mergeをやりたかった - くりにっき
tl;dr; 前置き GitHub Actionsでやる方法 Dependabot Auto Merge メリット デメリット 備考 Merge me! メリット デメリット Dependabot Pull Request Action メリット デメリット 番外編 Renovateを使う 近況 tl;dr; いくつかやり方はあるんだけどどれも一長一短で決定打はなかった 前置き Dependabot Previewの終了がアナウンスされました。 github.blog Auto-merge: We always recommend verifying your dependencies before merging them; therefore, auto-merge will not be supported for the foreseeable future. For those
質問をする技術 - くりにっき
以前社内に書いたポエムなんだけど年に1回くらい引用したくなるので公開した tl;dr; 質問をする時はゴールを提示する【MUST】 理由1 理由2 コンテキストを詳しく共有する【SHOULD】 期待してた結果(expect)と実際の結果(actual)を書く【IMO】 2020/7/22 12:30追記 2020/7/22 19:00追記 tl;dr; テンプレ 【質問内容】 【やりたいこと or 今困ってること or 質問の意図】 質問をする時はゴールを提示する【MUST】 なにかやりたい けど実現できない、うまくいかない それで質問する って感じに、質問をする動機としてまず やりたいことありき のはずなので、それを提示すべきです 理由1 質問される側（以下回答者）は質問内容がふわっとしていると色々なケースを想定して回答を組み立てます *1 例「Aの場合は～だけど、Bの場合は～」 こうい
Dependabotの設定ファイルを置くようにした - くりにっき
なにげなくDependabotを見てたらリポジトリに .dependabot/config.yml を置けることを気づいたので置いてみた https://dependabot.com/docs/config-file/ 設定ファイルを置くメリット いつも使ってる設定晒し 解説 default_assignees allowed_updates automerged_updates version_requirement_updates まとめ ちなみに .dependabot/config.yml をコミットしてると設定画面でこんな表示になります 設定ファイルを置くメリット 新しくリポジトリを作ってDependabotを導入する時にボタンをポチらずに済む 別リポジトリから設定ファイルをコピーしてくればいつもの設定が導入できる 設定をgitで履歴管理 いつも使ってる設定晒し Rubyだとこれ
AWS Lambda CI/CD俺的ベストプラクティス - くりにっき
Lambdaで動くアプリやフレームワークの事例はよく見るのですが、LambdaのCIやCDにしやすさに主眼をおいた紹介はあんまり見ないので現時点での自分のベストプラクティスのメモです tl;dr; このエントリで書いていること Lambdaをデプロイするのに肝になること デプロイしやすさに着眼したフレームワーク紹介 論外 コンソールからアップロードする できなくはないがかなり厳しい Terraform Apex 8/12 17:20追記 実用レベル Serverless Framework AWS SAM native extension問題と戦う Amazon LinuxのEC2インスタンス内でビルドする Amazon Linux互換のDockerイメージを使う Serverless Frameworkのプラグインを使う ライブラリをインストールするジョブとデプロイするジョブを分ける 【
CIマニアから見た各種CIツールの使い所 - くりにっき
社内外でちょいちょい聞かれるのでメモ。 前置き GitHubを使ってる場合 ライブラリを作ってる場合 Travis CIを選択する理由 2020/4/21追記 Travis CIを選択しない理由 アプリを作ってる場合 CircleCIとWerckerの共通点 CircleCIとWerckerの機能差異 GitLabを使ってる場合 GitLab CIの優位点 Jenkinsなどを使った方がいい場合 追記：2018/12/8 前置き 100%自分の主観なので偏ってます SaaSかオンプレならSaaS派。（自分でサーバの面倒身たくない） 自分が使ったことがないものは紹介していません 今回紹介してるTravis CI, CircleCI, Wercker, GitLab CI, Jenkinsに関しては仕事や趣味で各3〜4年くらいは使ってるはず GitHubを使ってる場合 ライブラリを作ってる場合
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
