クラウドの作り方（使い方じゃないよ）/ How to create Cloud Service2022/10/27に実施したNTT ComのOpen Techlunch #2の講演資料です
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
AWSのCLI作業はどこで行う？ 安全に管理するパターンとメリデメ集 | DevelopersIO
AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 AWS CLI、どこから使っていますか？ ざっくり、以下4種類のどれかを使っている方が多数派ではないでしょうか。 ローカル端末 AWS内に構築した管理用EC2にSSHを利用して接続 AWS内に構築した管理用EC2にSSM(セッションマネージャ)を利用して接続 AWS CloudShell 一体どう違うのでしょうか。 状況によって良し悪しは異なる
システム構成図をテキストで
Gigazineさんでdrawthe.netを取り上げていたので紹介です。使い方はGigazineさんのほうが丁寧なので、気になる方はチェックしてみてください。（2020年12月1日、追記） drawthe.netとは cidrblock/drawthe.netは複雑なネットワーク図も「テキストで書いてブラウザ上でSVGレンダリングできるようにしよう」というコンセプトのもと開発されたツールです。下図のように複雑な構成図も精度高く描くことができます。 拡大してみると情報量が多いこと、またいかに整っているかがわかると思います。 デモサイトも用意されているので、サクッと試したい場合はコチラが便利です。コードはGitHubで公開されています。更新が2017年末で止まってしまっているのが玉に瑕ですが、十分な性能を発揮してくれます。 drawthe.netを使いたい理由 美しい構成図といえばInter
Scaling Docker to Serve Millions More Developers: Network Egress | Docker
Scaling Docker to Serve Millions More Developers: Network Egress In Part 1 of this blog we went into a deep dive that analyzed all of the images stored in Docker Hub, the world’s largest container registry. We did this to give you a better understanding of how our new Terms of Service updates will impact development teams who use Docker Hub to manage their container images and CI/CD pipelines. Par
macOSでの開発環境を全部Docker化したらリストア時間が1時間半になった - The paradigm shift
どうも、リストア職人のさぼです。みなさんmacOSをどのぐらいの頻度でリストアしてますか？1年に1回はやってますよね？僕は3ヶ月に1回はやるようにしてます。綺麗な状態にしてOSが最大限のパフォーマンスで動いた方がいいし手元に入れたよくわからないアプリがずっと入ってるのって気持ちよくないじゃないですか。なのでMacを定期的にリストア(工場出荷状態に初期化)してます。 前回までは真っ白な状態からだいたい3時間ぐらいで普段開発している環境を構築できるようにしていたのですが今回から開発環境を全部Dockerにしてみようと思ってやってみたところ1時間半で開発環境を終えて作業開始できる状態までの最短記録を更新しました！ おわり(おわらない) いつもやってる手順を振り返りがてら紹介していきます。 Brewfile いつもリストア後は brew bundle コマンドでアプリやソフトウェアを入れるようにし
なぜ git rebase をやめるべきか - Frasco
Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
知って「おっ！」てなったGitHubの知識7選 - Qiita
GitHubダイスキー！ ということで、知った時に「おっ！」と感じたGitHubに関する事項を選出してみました。 あなたに「おっ！」と思ってもらえたら幸せです。 １．入れておくと、意味を持つファイル名がある。 README.md README.mdは有名ですよね。リポジトリのトップにREADME.mdという名称でマークダウンを入れておくと、GitHubで解釈されて表示されます。 それ以外にも、あるのです。意味のあるファイル。 ISSUE_TEMPLATE.md トップか、.github/というフォルダにISSUE_TEMPLATE.mdという名のファイルを入れると、GitHubでIssueを作った時にこのファイルの内容が入ります。書くべき項目を羅列しておくとルール化できていいですよね。 それ以外にも PULL_REQUEST_TEMPLATE.md を入れておくと、Pull request
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
現場がSubversionでつらい貴方へ…自分だけこっそりGitで開発する方法 - interprism's blog
この投稿は インタープリズム的「俺達私達の進捗を上げる25個前後のTips」 Advent Calendar 2015 - Qiitaの1日目 の記事です。 こんにちは、Imamotoです。 仕事に役立つTipsの紹介ということで、今日は最近自分の開発を快適にしてくれた豆知識として、現場はSubversionだけど自分だけこっそりGitで開発しちゃう方法を紹介します。 Subversionでのバージョン管理、捗ってますか？ 唐突ですが皆さん、現場でバージョン管理は捗っていますか？ バージョン管理システムはGitですか？それともSubversion(svn)でしょうか。 もしSubversionであり、尚且つSubversionであることに多少なりとも不満を感じているのであれば、 この記事はお役に立てるかもしれませんので気が向いたらご覧になってください。 Subversionのつらみ… 私は
git-svn の使い方メモ
git-svn.markdown git-svn の使い方メモ git-svn の使い方をメモする。他によいプラクティスがあれば指摘していただけるとありがたい。 用語 SVN のブランチと git のブランチが混在しているため、ここではブランチという語を以下のように区別する。 ブランチ、 SVN ブランチ：$SVN_REPO/branches 以下にあるディレクトリ ローカルブランチ：git のローカルブランチ リモートブランチ：git のリモートブランチ 例題の SVN リポジトリの構成 このメモでは SVN リポジトリが以下のような構造になっているとする。 $SVN_REPO/ foo/ bar/ branches/ foo-x/ foo-y/ bar-new-feature/ このリポジトリは標準レイアウトではない（trunk/ や tags/ がない）。トップレベルのディレクトリが
10分ではじめるGitBucket - Qiita
GitBucketとは GitBucketはたけぞうさんという方が開発されているGitHubのクローンアプリです。 Scalaで書かれており、驚くほど簡単に導入することができるのが特徴です。 OSSのGitHubクローンといえばGitLabがメジャーですが構築の手順が複雑かつ面倒なため、 使い始める前に構築段階で挫折した経験のある人も多いのではないでしょうか。 対するGitBucketはwarファイルを実行するだけという手軽さです、素敵!! より詳しいレビューはこのあたりを参照してください。 背景 とあるクラウド環境にGitBucketを導入する機会があり、 せっかくなので vagrant + ansible で導入を自動化するplaybookを書いてみました。 以下のクラウドプラットフォームで導入検証をしました。 AWS DigitalOcean したごしらえ Case: AWS vag
t32k、怒られる！セマンティック バージョニングしてますか？
どうも、バンクーバーでぶらぶらしている@t32kです。最近は暇なのでもっぱらOSS活動に勤しんでおります。そんなわけで日々のアプリケーション開発において重要になってくるのがバージョニングです。 今日はセマンティック バージョニングについて解説します。自身が公開しているライブラリやパッケージのコードを何かしら修正したら、それに伴いバージョンを上げるのが一般的だと思うのですが、実はどのようにバージョンを上げるのが適切なのか、昔の私は理解していませんでした。 『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』などと、なんとなくにバージョニングをしていました。 If the plugin’s API changes dramatically (for example, when sortOrder option is renamed
SourceTreeでいろいろ取り消してみる - yk5656 diary (旧)
SourceTreeでいろいろ取り消してみる 修正を破棄する（git checkout） 何かファイルを修正して、作業ツリーに修正ファイルが表示された状態。 この修正を破棄する場合は、破棄したいファイルで 右クリック（または[操作]メニュー）から[リセット...]を選ぶ。 [OK]ボタンを押すと修正が破棄される。 [リポジトリ]メニューの[リセット...]からも破棄することが可能。 ステージしたファイルの取り消し（git reset） Indexにファイルをステージした状態。 チェックボックスを外せば、ステージを取り消せる。 前回のコミットの修正（git commit --amend） コミットメッセージの修正 ファイルを修正してコミットした状態。 プッシュはしていない。 コミットメッセージを修正する場合は、 [コミット]をクリックして、下記の画面を表示する。 [オプションのコミット]で[
git でコミットした内容をなかったことにしたい（打ち消したい）時
コミットを打ち消したい時に使う reset と revert について。あとオマケでコミット前のものを打ち消す Discard についても。それぞれ SourceTree でどうやるのかも含めてメモ。 コミット済みだけれど push はしてない場合 コミット済み push 前なら「git reset」。 例）誤ってコミットしてしまったとか、いくつか試しにコミットしたけどこのコミット要らないなーとなった場合。 例）マージしないでいいブランチを誤ってマージしてしまった場合。 上記それぞれ細かくコマンドなど見たい場合、git reset についてもまとめてみる – murankの日記 が詳しかったです。 SourceTree で git reset 戻りたいコミットを選択して右クリックから「現在のブランチをこのコミットまでリセット」。push してない範囲だけが取り消せるという認識で戻りたいコミ
Jenkins Git publisherでデイリーリリースをタグ付けする - Qiita
どの変更分までをリリースしたりテストしたりしたかを確認する必要がでてきたため、 デイリーのリリース結果としてリリース用ブランチのタグ打ちを自動化した履歴 用意されてるものだけだと普通に出来るが、 ちょっと名前など工夫入れようとしたらハマったためメモ 前提 内部で利用しているGitLabからソースを取得している 通信の制約上Webhookでいい感じに使えない Pollingで頑張るしかない... Plugin Git plugin リポジトリでGitを使っているため利用 タグ打ちする時にも使ってる Environment Injector Plugin Git Publisherに渡すタグ名の環境変数を入れるために利用 やったこと 上記Pluginを入れておく Gitリポジトリから取得できるよういい感じになにがしかする RepositoryとCredentialsは通常通り設定 Advanc
Microsoft、業務PC自動セットアップツール「Windows AutoPilot」を提供
Microsoftは2017年6月29日（米国時間）、Windows 10の次期大型アップデート「Windows 10 Fall Creators Update」に向け、自社環境に適したPCのセットアップを自動化する「Windows AutoPilot」などの業務クライアント管理者向け新機能を提供すると告知した。 Windows AutoPilotは複数の管理機能を含めたスイートツールとして展開されるが、中でも目玉は「Windows AutoPilot Deployment」だという。Windows AutoPilot Deploymentは、IT部門が自社環境や組織の業務内容に応じてカスタマイズしたクライアント初期設定を読み出し、ユーザーがセルフビルドできるようにするクラウド型サービス。IT部門は、新たに導入するクライアントの配布準備業務を簡略化できる。 Windows AutoPilo
PowerShell Desired State Configuration（DSC）とは（前編）
PowerShell Desired State Configuration（DSC）とは（前編）：PowerShell DSCで始めるWindowsインフラストラクチャ自動化の基本（1/2 ページ） Windows OSの設定や構成を変更する場合、GUIの管理ツールを使うのが一般的である。だが台数が多かったり、構成変更や以前の構成への復旧などが頻繁だったりするとGUIでは非常に面倒だし、間違いもしやすくなる。こんな場合はPowerShell DSCを使ってインフラ構築作業を自動化するとよい。 連載目次 標準でGUI管理ツールを備えているWindows Serverでは、さまざまな設定・構築作業をGUIを通して手軽に実行できる。その半面、手動作業が必要なため、設定・構築に時間がかかったり設定を元に戻すのに手間が掛かったり、さらには複数のサーバーを同一の構成にそろえるのに苦労したりしがちだ。
ServerkitでMacの環境構築を自動化する - Qiita
Serverkit という構成管理ツールのチュートリアルとして、Macの環境構築を自動化する方法について説明します。 完成形 以下の手順で環境構築が完了できる状態にすることが目標です。 クリーンインストールしたばかりのMacを起動する Terminal.appを開く コマンドを1行入力する パスワードを入力する 各種アプリケーションがインストールされ設定が完了する r7kamura/dotfiles に動作するサンプルを用意したので、先に動作の様子を紹介しておきます。以下のコマンドでシェルスクリプトをダウンロードして実行すると、各種アプリケーションのインストールや設定の変更が行われます。1 $ curl -LSfs https://raw.githubusercontent.com/r7kamura/dotfiles/master/install.sh | sh Serverkitとは 上
Serverkitつくった - ✘╹◡╹✘
ChefやAnsible、Puppet、Itamaeなどの構成管理ツールをあまり使ったことがなく、勉強のためにServerkitというのをつくってみたので、現状こういう感じでやってみましたというのを書き残しておく。作り手の気持ちになればこそわかるものがあるだろうと思う。 ところで去年も似たような記事を書いた。 概要 Serverkitというのは、前述した通りChefやAnsibleのような構成管理ツール。マシンの理想的な状態をレシピと呼ばれるファイルに定義しておき、現在のマシンの状態と比較してその差分を埋めるためのもの。Rubyで書かれていて、手元にversion 2.0.0以上のRubyと、Serverkit、それからServerkitが利用している幾つかのライブラリが入っていれば動作する。Serverkitを動かすマシンと同じマシン、もしくはSSHで接続できるマシンに対して実行できる。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
