PHPカンファレンス関西2024での発表資料です https://fortee.jp/phpcon-kansai2024/proposal/42712995-5f3e-4c68-a951-39584eac95a1

はじめに 最近Fluentdを使い始め、あまりの使い心地の良さに「ああ、最高だ」という気持ちになったため、素晴らしさを共有すべくこの記事を執筆することに致しました。一からFluentdを自分でやろうとすると中々手が出なかったり、「完全に理解した」という状態になるまで二日くらい掛かったりするので、それがこの記事を10分程度読むだけで200倍くらいの時間圧縮に繋がれば良いなと思います。少なくとも自分だけで一から学ぼうとするよりはるかに効率が良いと考えております。 Fluentdは高信頼性のデータ収集ソフトウェア Fluentdはオープンソースのデータ収集ソフトウェアで、多機能で、高速かつ信頼性高くデータ転送を行ってくれます。なぜ信頼性が高いのかというと、データ転送時に一時的にバッファーに情報を蓄積出来る機構を持っているため、障害が発生してもログの再送制御を行い欠損を防ぐことが出来るからなんです

マシンユーザーを作成する 一般的なユーザーを作るときと同じように作成します。 メール通知などが来るので、開発用の共有メールアドレスなどがあればそちらを使ったほうが良いかも。 マシンユーザにPersonal access tokenを発行する Githubにマシンユーザでログインして、下記にアクセス。 https://github.com/settings/tokens/new (ユーザーのSettings -> Developer Settings -> Personal access token)から発行します。 マシンユーザに操作したいリポジトリのRead権限を与える リポジトリのSettings -> Manage access -> invite teams or people（https://github.com/{リポジトリのURL}/settings/access）から マシ

並列実行とテスト分割機能を使用すると以下を実現できます。 CI/CD パイプラインのテストにかかる時間の削減 テストを分割する Executor の数の指定 CircleCI CLI が提供するオプション (名前やサイズに基づいて、またはタイミングデータを使って) によるテストスイートの分割 パイプラインは、多くの場合コードがコミットされるたびに一連のテストが実行されるように設定されます。 プロジェクトに含まれるテストの数が多いほど、 1 つのコンピューティングリソースで完了するのに時間がかかるようになります。 この時間を短縮するために、複数の並列の実行環境でテストを分割し、実行することができます。 テスト分割は、CI/CD パイプラインのテスト部分を高速化できる優れた方法です。 テスト分割機能を使用すると、1 つのテストスイートのどこで分割するかを以下によりインテリジェントに定義できます

トランスクリプト Protsenko氏：私の名前はMykytaです。Netflixで働いています。私の仕事は基本的に、他の開発者が遅くまで職場に残らなくてもいいようにすることです。彼らが午後5時に退社しても生産的であることが私の実現したいことです。私はプラットフォーム組織、つまり生産性エンジニアリング部門で働いており、他のエンジニアのために労力を抽象化しようとしているのです。エンジニアが同じ退屈な技術的問題に何度も対処するのではなく、ビジネス上の問題の解決に集中できるようにします。 いくつか質問させてください。あなたたちのうち何人が、自分で作って自分で動かすという哲学を実践している会社で働いてますか？生産現場との間にゲートキーパーがいないこと、機能や修正をより早く提供できることに満足している人はどれくらいいますか？本番環境で発生したインシデントに対処しているときに、どうすればいいのか分から

Agile Journeyをご覧の皆さん、こんにちは。ZOZOの御立田です。 私が所属する株式会社ZOZOは、「世界中をカッコよく、世界中に笑顔を。」を企業理念として掲げ、ファッションEC「ZOZOTOWN」、ファッションコーディネートアプリ「WEAR」などの各種サービスの企画・開発・運営や、「ZOZOSUIT」「ZOZOMAT」「ZOZOGLASS」などの計測テクノロジーの開発・活用をおこなっています。また、カスタマーサポート、物流拠点「ZOZOBASE」を運営しています。 ファッションコーディネートアプリ「WEAR」やショップスタッフの販売サポートツール「FAANS」を手がける、私が所属するブランドソリューション開発本部では、「開発生産性を3倍に」を目標に掲げ、多くの改善を進めています。 「開発生産性」をどのように定義するかには議論がありますが、まず私たちが向き合ったのは「仕事量の生産

要約 特定のブランチへの直 push を禁止するためにはブランチ保護ルールを追加するだけでは足りず、マージ前の PR またはステータスチェックを必須にする必要があります。 保護ブランチ 目的 意図しない変更が入らないようにブランチを保護します。 設定方法 リポジトリの Settings > Branches > Branch protection rules > Add Rule で設定できます。 Branch name pattern に保護したいブランチ名を入力します。 パターンも使えるので milestone/* のような指定もできます。詳細はドキュメント参照。 直 push を禁止するためにはマージ前の PR またはステータスチェックを有効にする必要があります。 ステータスチェックが不要であればマージ前の PR にチェックを入れれば十分です。 Include administrat

デプロイに伴うダウンタイムが好ましくないのは、クラウドの登場以前も同じでした。 多くの企業は、アプリケーションをホストする従来のデータセンターでローカル ユーザーからのアクセスに制限を設け、ユーザーによるアプリケーションの利用頻度が低い深夜などの時間にデプロイ スケジュールを設定するといった工夫をしていました。 クラウドをベースにした 24 時間年中無休の環境が広く普及すると、あらゆるタイムゾーンから四六時中アクセスが来るようになり、デプロイを設定しやすい時間帯はなくなりました。 現在はどの企業でも、アプリケーションを利用するかもしれないすべてのユーザーに対して、アクセスできない時間帯を作らないことが課題になっています。 以前は、変更や更新のデプロイ時にアプリケーションをオフライン状態にする手法が一般的で、これによってダウンタイムが発生していました。 現在では、アプリケーションのビルドから

最高の開発者体験を目指して AWS CDKでCI/CDパイプラインを 改善し続けている話 株式会社ニューズピックス 安藤 裕紀 2023.3.20@CI/CD Conference 2023 by CloudNative Days

はじめに 先日、下記のようなツイートを見つけて、そういえば趣味で個人開発してたときには然程気にしてなかったけど、仕事で運用するようになって先輩たちから学んだり自分で身につけたチップスってちょこちょこあるよねー、とふと思ったので、Webアプリケーション開発に関わるものをいくつかまとめてみました。 特に体系的/網羅的という程でもないですし、最近はFWや色々な仕組みでカバーされてるものも多いですが備忘録として。 Tips 機械が読めるログを作る これは割と重要なのですが、ログは人間が読むものではなく機械が読むものです。それはZabbixだったりDatadogだったりSplunkだったりgrep/awkだったりツールは何でも良いのですが、古の時代はさておき現代ではログは機械が読めることが最重要です。 まず大前提として構造化されている必要があります。言うまでもないですが「フリーフォーマット」のログの

開発組織を柔軟に動かし、エンジニアのパフォーマンスを最大化させる上で、「リーダーシップ」の定義は欠かせません。組織の価値最大化を求められるマネジメントレイヤーならば、どのような形で組織に関わっていくべきか、日頃から頭を悩ませているはずです。 ここで、エンジニアを「率いる」のではなく「支援する」という視点でリーダーシップのあり方を考えたとき、どのような組織のフォーメーションが想定できるでしょうか。 リクルートは、「エンジニアを支援し、エンジニアの生産性を向上させるための組織」として開発組織を定義。結果的に、ピラミッドではなく「バリューチェーン」として組織を捉える、というユニークな発想へたどり着きました。 バリューチェーンの中では、エンジニアの“後方支援”に特化した専門職が開発のフェーズごとに配置され、さまざまなアプローチで組織を下支えしています。その姿はまるでサッカーのフォーメーションのよう

こんにちは。シニアスクラムマスターの天野 @ama_ch です。 サイボウズの開発組織において、今後の成長を加速させるためには、組織の基本単位をスクラムチームのような自律的な小さなチームにしてスケールさせることが非常に大切だと考えています。サイボウズは比較的スクラムが普及している組織ではありますが、組織内のすべてのチームがスクラムを採用しているわけではありません。 フレームワークとしてスクラムを採用するかどうかはチームの自由です。しかし、健全なチーム環境を整えることはすべてのチームにとって重要です。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報がないことが悩みでした。 そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践し

Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

株式会社サイバーエージェントでバックエンドエンジニアをしている江頭です。 今回、私たちのチームにトランクベース開発という手法を取り入れることによって、デリバリーの速度と開発効率が上がり1日に多いときで15回以上本番デプロイができました。 この記事では、トランクベース開発とはどのような手法なのかご説明したあとに、実際に導入してわかったことをご紹介したいと思います。 トランクベース開発とは トランクベース開発とは、ソースコードのバージョン管理手法です。現在一般的な手法であるGitflowでは、機能毎にブランチを作成し 1つの機能実装が完了するまでそのブランチで作業し、コードレビュー完了後に各役割ごとに存在するブランチへマージします。 Gitflowでは1つのブランチへ長時間にわたり変更を加えるため、次のような課題があります。 メインブランチへのマージの際に差分が多くコンフリクトが発生する可能性