フィードバックを送信 Terraform を使用するためのベスト プラクティス コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このドキュメントでは、複数のチームメンバーやワーク ストリームで Terraform を使用した効果的な開発を行うためのガイドラインと推奨事項について説明します。 このガイドでは Terraform の概要は説明しません。Google Cloud で Terraform を使用する方法については、Terraform を使ってみるをご覧ください。 スタイルと構造に関する一般的なガイドライン 以下の推奨事項は、Terraform 構成の基本スタイルと構造を対象としています。この推奨事項は、再利用可能な Terraform モジュールとルート構成に適用されます。 標準のモジュール構造に従う Terraform モジュールは、標準のモジュ
この記事について 簡単な電卓アプリ開発を例に、以下を行います GitHub上でのIssueテンプレート、マイルストーン、Projects(カンバンボード)の設定 GitHub Flowを例にした簡単な開発の流れの説明 CMakeを用いた、C++プロジェクトの用意 GoogleTestを用いたUnit Testの導入 GitHub Actionsを用いた、CI/CDの導入 クロスプラットフォーム (Windows, Linux, MacOS, Linux(ARM)) GitHub Actionsを用いた、コードの静的解析 この記事では、開発の方法論はおまけとして、それを支えるためのツールの設定方法に重点を置きます 1人でやる個人開発～数名規模での開発は本記事の内容でカバーできると思います。もっと複雑になると別の仕組みが必要になってきそうです 本記事の設定を全てやる必要はなく、必要そうな項目を
CircleCI API v2で自由自在に業務ワークフローのタスクを実行する - KAYAC engineers' blog
ごきげんよう、CI日和ですね。技術部の谷脇です。 先日Jenkinsでテストを実行したり、Slack Botからトリガーして実行していた業務ワークフローの必要なタスクをえいやっとCircleCIに持っていったのでその話をします。 長いので要約すると ヘビーにJenkins使ってたのを全部CircleCIに持っていきました。自動テストとSlack Botからトリガーされるジョブです CircleCI 2.1の機能をつかって設定を書きました。いい感じです テスト以外でBotからキックするようなジョブはそのままだと難しいので、プレビューリリースのCircleCI API v2を使いました。必見です 自前運用のJenkinsさんお疲れ様でした テストを継続的に動かす環境といえばJenkinsです。カヤックでも多くのプロジェクトでテストや、その他様々なタスクを実行する環境として利用されてきました。
Postman をチームで運用していくためにフォーク機能を使ってみた - Techtouch Developers Blog
バックエンドエンジニアの misu です。TENET や羅小国戦記などわりと映画を見て最近は楽しんでいます。この記事を完成させたらクイーンズ・ギャンビットを見たいところ。。！ この記事について 前回、Postman を使って E2E テストを行う記事を書いたのですが、チームで運用してくとなると少し工夫が必要になったのでその辺の Tips を書いて行きます。 具体的には Postman のコレクションを git のようにフォークして、各開発者が開発ブランチごとに E2E テストを回せるようにしました。 内容 背景 下記図のように複数の開発者が1つのコレクションに対して、API を登録すると E2E のときに A は users API がないため CI が落ちてしまいます。B もまた然り。 本当に E2E 含め開発完了しているかは、落ちた E2E の結果を見て、開発スコープ以外のものだったら
Amazon SageMakerを利用したエンタープライズのためのMLOps基盤ロードマップ | Amazon Web Services
Amazon Web Services ブログ Amazon SageMakerを利用したエンタープライズのためのMLOps基盤ロードマップ この記事はMLOps foundation roadmap for enterprises with Amazon SageMakerを翻訳したものです。 企業が組織全体で機械学習 (ML)の採用を進めるにつれて 、MLモデルの構築、学習、デプロイのための手動ワークフローがイノベーションのボトルネックになる傾向にあります。これを克服するために、企業はデータサイエンティスト、データエンジニア、MLエンジニア、IT、ビジネス関係者などの複数のペルソナがどのように協業すべきか、懸念事項、責任、スキルをどのように分離するか、AWSのサービスをどのようにして最適に使用するかなどについて明らかにし、明確な運用モデルを構築する必要があります。 このようなMLと運用
のがもはや半年前だけど記録として書いておく。結論を書くと、ecs-deployからecspressoに乗り換えるのはすぐできるし、タスク定義が管理しやすくなるのでおすすめです。 https://github.com/kayac/ecspresso もともとNature社では僕が入社する前からecs-deployが使われていた。これは、コンテナイメージをすげ替えてdeployするだけであればシンプルでわかりやすい。ただ、以下のような課題があった。 タスク定義自体を変更したい時にecs-deployだけでは対応できない ソースがbashスクリプトで年々複雑になっており(僕には)読みづらい 実際度々メンテナンスが滞ったりforkがいくつかあったりする jqやawsコマンドに依存している それに対して、ecspressoは以下のような利点があった。 タスク定義ごとリポジトリ管理できる Goなので(
CircleCI での Android プロジェクトのビルド設定と自動化の工夫 | メルカリエンジニアリング
この記事は、Mercari Bold Challenge Month の 7 日目の記事です。 こんにちは。メルペイの Android チームでネット決済 (オンラインでの決済手段) の機能開発や開発基盤の改善に取り組んでいる @KeithYokoma です。 メルペイの Android チームでは CI (Continuous Integration) ツールとして Bitrise と CircleCI を使っています。それぞれを使い分けており、日々の開発フローの中でリポジトリに変更をプッシュする場面で CircleCI を、それ以外に開発に必要な成果物の生成 (たとえば API の定義から各言語用のライブラリを吐き出す) 場面で Bitrise を利用しています。 この記事では、Android プロジェクトのビルドにあたって CircleCI をどのように活用しているか、またどんな工夫
Issueとは、Github上で作成できる、ToDoリスト的なもの 使い方 Webサイトのメニューバーをハンバーガーメニューに変更したい Github上で、１の旨を記載したIssueを立てる マークダウンでコメントを書けるので便利 画像も載せられるので、こんなメニューにしたい、というイメージ図も載せておける feature/#12_replace_to_hamburger_menuというブランチを作成 Issueを立てるとそのIssueに番号、例えば#12が割り振られるので、それをブランチ名に含める 開発進める 開発完了 Issueに書いた内容のタスクが完了したので、developブランチにマージコミットする この際、close #12などとコミットメッセージに記述すると、自動的にIssueが閉じられる Issueを使うメリット Github上でタスク管理できる コミットするとIssueも
持続的なアプリ開発のための DX を支える技術 #DroidKaigi 2020 - Infinito Nirone 7
この記事は、DroidKaigi 2020 で発表予定だったセッション「持続的なアプリ開発のための DX を支える技術」を解説するための記事です。 セッション概要 Android の歴史はすでに 10 年を超え、数多のアプリケーションがストアで公開されています。これらのアプリケーションの中には、何年も継続的にバージョンアップを重ねているものもたくさんあります。 このセッションでは、このような持続的なアプリケーション開発・リリースをうまく回す秘訣として DX という言葉をとらえ、アーキテクチャやテストのほか、日々の開発に関わるワークフローをメンテナンスするための考え方や手立てとして、モバイル CI や Android 向け各種ツールキットの導入と効率化、Gradle をベースにした独自タスク開発の方法などを紹介します。 資料 speakerdeck.com 一部実装の詳細を資料に委ねています
はじめに 2020年10月、Githubがデフォルトのメインブランチ名をmasterからmainに変更しました。理由は、masterがslave（奴隷）を背後に連想させるため。 旧来の価値に根差した既存の用語を置き換える動きは、2020年を契機としてますます勢いを増し、その影響は仕様の策定から命名規則などのコーディング面にまで幅広く及んでいます。 こうしたアメリカのテック界の様相をInclusive Writingの切り口から、Google, Appleのスタイルガイドを摘要しながら概観するのが本稿の趣旨です。 Inclusive Writingとは？ Inclusive Writingはかんたんには、多様な読者を意識した書き方、といえます。 Inclusiveは日本語でも「インクルーシブ教育」等、ダイバーシティの文脈でカタカナ語として定着しつつありますが、強いて訳せば「包含、包み込む」と
Figmaconfig2022で発表されたComponent PropertyとAutoLayoutについても追記しました。 2023年にリリースされたVariables、NestedComponentに対応しました。 2024年のmulti-editに対応しました。 このドキュメントの目的デザインガイドライン・システムに関する理解を深め、UIUXを通したプロダクト価値の最大化が業界として底上げされるといいなと思っています。 あとは、私rikikaが個人的にいろいろなお仕事で作らせて頂く機会をいただくのですが、そのたびに事例や作り方のハウツーが目まぐるしく変わっていき、インターネット上に情報が散らばっていると感じていたのでそのsingle source of truthの役目を担いたいという気持ちもあります。 とはいえ、絶対これが正しいというのもない分野だと思うので、全体感を通して適宜コメ
Last Commit Date of Markdown Sources: Tue Oct 25 10:20:24 2022 +0000 i The Rust Programming Language 日本語版 著：Steve Klabnik、Carol Nichols、貢献：Rust コミュニティ このテキストのこの版では Rust 1.58（2022 年 1 月 13 日リリース）かそれ以降が使われているこ とを前提にしています。Rust をインストールしたりアップデートしたりするには第 1 章の「インス トール」節を読んでください。 HTML 版は https://doc.rust-lang.org/stable/book/で公開されています。オフラインのときは、 rustup でインストールした Rust を使って rustup docs --book で開けます。 訳注：日本語の
GitHub Flowとは - Qiita
git-flowとは まず、GItHub Flowと似たものにgit-flowがあります git-flowとは数あるGitのブランチ戦略の1つで、A successful Git branching modelが基になっています。 以下はgit-flowの有名な図 (https://nvie.com/posts/a-successful-git-branching-model/) masterのメインブランチがあり、開発用のdevelopブランチ、そして機能毎のfeatureブランチや緊急用のhotfixブランチが存在し、これらのブランチを使い分けて開発・リリースを進めていきます。 GitHub Flowもgit-flowと同様にブランチ戦略の1つであり、その名の通りGitHubで利用されているフローです。 GitHub Guides GitHub Flowではメインのmasterブランチ
git-flow 図解 - Qiita
git-flow is Vincent Driessen さんがブログで公開した A successful Git branching model のこと 元記事：A successful Git branching model 日本語訳： A successful Git branching model を翻訳しました または、A successful Git branching modelを補助するためのツールの名称 git-flow cheatsheet ブランチの運用ルール、命名規則を設けることで、 複数人開発時も各ブランチをわかりやすい状態に保つことができるようになる もっとシンプルなルールにしたものに、GitHubFlowがある 元記事：GitHub Flow 日本語訳：github-flow.ja.md 小さなサイクルでデプロイするケース向き この記事では、A success
今回の記事は上記のような方におすすめ。 今回の記事では、Gitブランチの命名規則について…Git初心者でもわかるよう、わかりやすく解説いたします！ 先輩に「適当につけといて…」と言われて一番困るものの１位がブランチ名ではないでしょうか。「適当って言われても、その適当がわからないから困ってるんだよ！」とキレたくなる方も多いかもしれません。ですが、本日は命名規則を７つ「厳選して」お伝えいたします！ 本記事の内容 命名規則のメリット【開発効率化！】永続ブランチと一時ブランチGit ブランチ７つの命名規則【厳選】 なおこの記事は3分で読める内容です。 命名規則のメリット【開発効率化！】 チーム内で命名のガイドラインを策定し、記述方法を統一することで、どんなメリットが得られるでしょうか？ 一言で言えば「より開発を効率化する」ことが可能です。適切にブランチが命名がされていなければ、いざ過去のコードを探
git-flow 図解 - Qiita
git-flow is Vincent Driessen さんがブログで公開した A successful Git branching model のこと 元記事：A successful Git branching model 日本語訳： A successful Git branching model を翻訳しました または、A successful Git branching modelを補助するためのツールの名称 git-flow cheatsheet ブランチの運用ルール、命名規則を設けることで、 複数人開発時も各ブランチをわかりやすい状態に保つことができるようになる もっとシンプルなルールにしたものに、GitHubFlowがある 元記事：GitHub Flow 日本語訳：github-flow.ja.md 小さなサイクルでデプロイするケース向き この記事では、A success
背景 会社はGithubでGitflowを管理しています。最近開発の業務が大幅増えてきて、ブランチの数も以前より何倍になりました。Gitブランチについて、現状は下記となります。 1. 大きな機能に対して、featureブランチを作成して、細かい機能は更にチケットを切ってfeatureブランチ向けのPRを作って作業します。 2. テスト環境のデポロイやリリースのために、github actionでスクリプトを作って、毎回featureブランチ向けのPRがマージされたら、自動的にデポロイやリリース用のブランチへPRを生成します。 3. 毎回リリースの直前にfeatureブランチの内容を確認して、リリースを行うとなります。 気がついたところ 最近はGitブランチの管理で下記の何点に気が付きました。 1. Sub-featureと所謂細かい機能を改修するブランチが多いので、ブランチの管理が難しくな
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Terraform を使用するためのベスト プラクティス | Google Cloud
GitHubでC++プロジェクトを開発する際にやっておきたい設定 - Qiita
ecs-deployからecspressoに乗り換えた | おそらくはそれさえも平凡な日々
【Git】ブランチの命名規則を調べてたらIssueドリブン開発という存在を知った - Qiita
やさしくて難しいInclusive Writing入門 ～GoogleとAppleのスタイルガイドを読む
デザインシステム完全版｜Figmaでの作り方、事例など【2024年版】｜rikika
The Rust Programming Language: 2018 Edition
【Git】ブランチ命名規則と開発効率化【7つのベストプラクティス】 - アラサーPHPerの日常
Gitブランチでフォルダーの運用 - Qiita