Backlogを安定して運用し全てのお客様に安心してご利用いただくために、2020年9月上旬からGitリポジトリのサイズとGitリポジトリ内のファイル単体のサイズを制限します。これらのサイズの制限を超える場合、リポジトリへのプッシュはブロックされます。大きすぎるファイルを管理する方法として、後述のGit LFSやファイル共有を推奨します。 適用される制限、制限の背景、制限の対象と適用スケジュール、制限にともないお客様でご対応が必要なケースについてご説明します。 適用される制限 2020年9月上旬より適用される、Backlogの各プロジェクトに存在するGitリポジトリのサイズ（以下、リポジトリサイズ）とGitリポジトリ内のファイルサイズ（以下、ファイルサイズ）の制限について、具体的に説明します。 ファイルサイズは最大100MBまで ファイルサイズは100MBを上限とし、それ以上は制限の対象と

BacklogのGitリポジトリからチェンジログを生成するツール「gbch」 を開発したので、開発の動機や使い方についてご紹介します。(Backlogの公式ツールではありません） 要約 BacklogのGitリポジトリのコミットログからプルリクエストを介したマージコミットを収集してチェンジログを自動生成するツールです。 GitHubリポジトリでチェンジログを生成するツールの github.com/Songmu/ghch をフォークしてBacklogの仕様に合せて改造しました。（gbchのチェンジログはghchで生成しています） Markdown記法とBacklog記法の出力に対応しています。 基本的にはSemver（Semantic Versioning）に沿った形式のタグに対応しており、オプションでタグのプレフィックスを任意の文字に変更できます。 オプションでヌーラボアカウントと連携して

BacklogのSREを担当しているmuziです。 今回の記事では、ヌーラボにおけるSREの活動事例として、Backlogの課題検索機能のリプレイスプロジェクトについてご紹介します。 このプロジェクトでは、SREと開発者がチームを組んで、要件定義からリリースまで行いました。その結果、Backlogを構成するサーバ同士が疎結合になり、将来的なマイクロサービス化に向けた足がかりを作ることができました。 歴史の長いプロダクトにありがちな技術的負債への取り組みの一例として、みなさんの参考になれば幸いです。 リプレイスプロジェクトの背景 Backlogの課題検索機能 最初に、このリプレイスプロジェクトの背景として、Backlogの課題検索機能についてご紹介します。 課題検索機能とは、Backlogの「課題」ページで利用できる検索機能のことです。件名や詳細に対するキーワード検索に加えて、プレミアムプラ

要約 gitbコマンドは、Backlogが提供するGitに関連する操作を補助するツールです。 例えば、現在のリポジトリやブランチに紐付く課題やプルリクエスト等のBacklogが提供する画面を、1コマンドでブラウザから開けます。 全てのgitコマンドをgitbコマンド経由で実行できるので、コマンドを入力する際に両方を意識せずに操作できます。 さらに、エイリアスを設定すると、git pr 、git issue のように、あたかもgitコマンド自身のサブコマンドの如く使用できます。 提供する機能 gitbコマンドで具体的にどのようなことができるのか、提供する機能について一部抜粋して解説します。 リポジトリに紐付く情報を1コマンドでブラウザから開ける 例えば、現在のブランチに紐付くプルリクエストや課題、現在のリポジトリのブランチ一覧、タグ一覧、そしてコミットログ等のBacklogのページを1コマン

こんにちは、Backlogチームの小久保です。Backlogチームでは、約4年続いたBacklogをJavaからScala / Play Frameworkに移行するプロジェクトについて、2日間かけてふりかえりをしました。そのとき得られた知見を整理してみました。 長くやってきたプロジェクトを振り返ると、プロジェクトに大きな影響を与えた決断がいくつか必ずあります。その決断が正しかったのか、今後の自分たちの重要な意思決定をどう改善していけるか、しっかり考えるためにも効果的にふりかえりをすることが大切です。 本記事では、ITツールの活用方法や特定のプロセスの話は出てきませんが、Backlogチームがおこなった、長期プロジェクトを振り返るために役立ったことを整理してお届けします。 プロジェクトの内容とふりかえりをした理由 Backlog Play化プロジェクトとは、Backlogの動作環境、コード

こんにちは、Backlog SREチームのmuziです。 この記事は SRE Advent Calendar 2019 の10日目、およびBacklog Play化プロジェクトブログの番外編です。 先日のブログ記事「SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】」の後半では、Play化プロジェクトの終了後に、開発チーム自身によるオンコール対応の取り組みを始めたことを軽くご紹介しました。 私を含むBacklogのSREチームは、このオンコール対応を助けるためのアラート通知システムを作り、開発者なら誰でも使える形で提供しています。この記事では、前回のブログ記事では書ききれなかった、このシステムの詳細をご紹介します。 同じような問題意識を抱えていて、これからオンコール対応を見直したい、と考えているSREや開発者の参考になれ

一般的に、自律型のチームは他律型のチームよりも開発のスピードが早く、問題を未然に対処できると言われています。自律型のチームに不可欠な要素として、「何でも言いやすい雰囲気」「居心地の良さ」の創出があります。これらは「心理的安全性」とも呼ばれ、米グーグル社が「チームの生産性を高める唯一の方法」として発表したことで大きな注目を集めています。 「バグや障害の多発」「エンジニアの離職率の高さ」「リリースの延期」といった現場の問題解決に心理的安全性がなぜ効いたのか。心理的安全性を創出したプロセスと失敗から学んだ教訓など、現場担当者の視点を対談形式でお伺いします。 ■自己紹介（左から） CAMPFIRE プロダクトマネージャー 久津 佑介（ひさつ・ゆうすけ）さん 印刷会社でエンジニア、開発会社でエンジニアチームのマネージャーを経て、2019年に株式会社CAMPFIREに入社。プロダクトマネージャーとして

こんにちは。Raspberry Pi4でようやくギガビットLANにネイティブ対応したことにテンションが上がっているBacklog開発チームの佐藤です。 ヌーラボでは2015年11月から2019年の7月まで、BacklogをJavaからScala / Play Frameworkに移行するという大規模なリプレイスプロジェクト（以下、Play化プロジェクト）を行っていました。 私は2017年の夏からプロジェクト完了までこのプロジェクトに参加していました。 今回の記事では、Play化プロジェクトに途中参加した立場で、プロジェクト中に起きた出来事と当時の心境、問題をどう乗り越えたのか、反省と教訓についてもお届けします。 プロジェクトに参加する前は何をしていたか 出来事：Backlogの機能改善チームからPlay化プロジェクトチームへ移動 心境：不安だがトップダウンで決まったのではなく、自分自身の意

Backlog SREチームのmuziです。2018年4月から2019年7月まで、BacklogをJavaからScala / Play Frameworkに移行する大規模なリプレイスプロジェクトに参加していました。 SREとして、このリプレイスにはかなりの困難が伴いました。特にBacklogのサービス安定性は大きな問題でした。 本記事では、こうした問題に対して、SREである私がどういうアプローチを取ったのか、そしてこのプロジェクトで得られた教訓を今後チームや組織全体でどのように活かそうとしているかをご紹介します。 正直言って、泥臭い話だらけの内容です。それでも、技術的負債を抱えたプロジェクトでSREが取れるアプローチの事例の一つとして、読者の参考になれば幸いです。 はじめに ヌーラボでは2015年11月から2019年7月まで、BacklogをJavaからScala / Play Frame

ヌーラボの松本です。「Backlog Playプロジェクト」に2017年2月から途中参加し、プロジェクト解散の2019年7月までメンバーの一員として動いていました（プロジェクトの概要は 時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話をご覧ください）。 このBacklog Playプロジェクト(以下、Play化プロジェクト)では、期間によって私の役割は変わりました。 参加した当初は開発メンバーとしてコードを書いていましたが、2018年4月からプロジェクト終了の2019年7月までは、開発をしながらプロジェクトの取りまとめをしていました。 マネジメントのような役割ははじめてだったので、いろいろ未熟な点もありましたが、プロジェクトの機能リリースを早めるために、不具合対策や手戻り削減といった問題と向き合いました。 本記事では、私のPlay化プロジェクトでの役

ヌーラボでScalaを書くRubyistの谷本です。ヌーラボでは、Backlogの開発を担当しており、最近ではBacklogをJavaからScala / Play Frameworkに移行するプロジェクトのメンバーでした。 BacklogのPlay化プロジェクトでは、OutOfMemorryError(以下、OOM)の発生やCPU使用率とロードアベレージが上がったままという、Java Virtual Machine（以下、JVM）上で動くBacklogのパフォーマンスに関する問題に対処すべく、何度かHeap/Thread dumpを見る機会がありました。 私がPlay化プロジェクトで取り組んだパフォーマンス改善の知見や経験をもとに、本記事では「JVMで起こったパフォーマンスの問題の切り分け方」についてお届けします。 はじめに 本番環境でしばらく動かしていると、コード自体は正しく実行できるけ

ヌーラボの江口です。約8年間Backlogの開発を担当しており、BacklogをJavaからScala / Play Frameworkに移行するプロジェクトには最初から最後まで関わりました（プロジェクトの概要は時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話をご覧ください）。 本記事では、BacklogのScala / Play Framework化プロジェクトで「Backlogのサーバーサイドを進化させる“土台”を作る」をテーマに、どのようにBacklogのアーキテクチャを設計・実装したのかご紹介します。 はじめに 私は2012年の入社以来、Backlogの開発を担当しています。Backlogは10年以上続くサービスであるため、度重なる機能追加や修正を行うことで複雑化し、日頃開発をする上で様々な問題を感じていました。 今回のBacklogのSca

ヌーラボの松浦です。私がSREのエンジニアリングマネージャーとしてプロジェクトのサポートに携わっているプロジェクト管理ツールのBacklogは、2019年7月にJavaからScala / Play Frameworkに完全移行をしました。 このPlay化プロジェクトは、10年がかりで改良され仕様が明文化されていなかったBacklogを、JavaからScala / Play Frameworkに移行するという壮大なプロジェクトでした。 約4年にわたる「Backlog Playプロジェクト」(以下、Play化プロジェクト) で体験した“紆余曲折”を記録に残し、後のプロジェクトにつなげるために、今回から7回に渡って、技術的な挑戦やプロジェクト管理の視点など、当時のチームメンバーが独自の目線でPlay化プロジェクトを振り返った記事を連載します。 連載第1回目の本記事では、序章としてPlay化プロジ

Backlog開発チームの藤田です。皆さんは子どもの頃、夏休みの宿題にどんなふうに取り組んでいたでしょうか？ 夏休みの初めに一気に終わらせてしまう 毎日こつこつ進める 夏休みの終わり近くになって必死でやる 終わらせない などいろんなタイプがありますね。 私は「初めに一気に終わらせる」タイプでした。毎日こつこつ進めるとかは無理と自分でわかっていたので、先にやってしまって安心したかったのだと思います。「終わらせない」を選択できるほど肝が据わってもいませんでした。 本記事は、普段私たちが業務で使っているプロジェクト管理の手法を夏休みの宿題に応用したお話です。小学2年生になった娘と一緒に「夏休みの宿題完遂」を目的に、バーンダウンチャートなどを活用して、プロジェクトをどのように進めたのかお届けします。 夏休みの宿題をマネジメントする事の発端 うちの子にかぎって 私には小学校6年生と2年生の娘がいます

こんにちは、お久しぶり、初めまして。Backlog開発班の川上です。私は現在Backlogのアカウント認証、契約、お支払いに関する機能をヌーラボの共通基盤である「ヌーラボアカウント」に統合するプロジェクト(長い！)のチームに参加しています。 このチームではアジャイルソフトウェア開発手法の1つであるスクラムを取り入れており、そのなかでいくつかの改善をおこなってきました。今回はスクラムを用いたBacklogの開発改善のなかでも、うまくいっているものを2つ紹介します。 取り組みその１. ペアプログラミング 遡ることプロジェクト立ち上げ時、チームにはBacklogの実装や開発に使うプログラミング言語であるScalaに明るくないメンバーもいたため、どうにかしてそれぞれの知識を伝達する必要がありました。 そこでペアプログラミングを取り入れたところ、無事メンバーそれぞれが一人でも不安なくやっていけるよう

仕様や画面は現行バージョンと異なる可能性があります。 Backlogの最新版についてはこちらからご確認ください。 本エントリーは Backlog Advent Calendar 2017の12月18日の担当分です。 ITかぁちゃんこと平さんからバトンが回ってきました！ヌーラボのコンテンツマーケターの@fomifomi0207です。いよいよクリスマスまであと6日！2017年は残り13日となりました！師走の12月はなにかと慌ただしいですが、今年のタスクは今年中に綺麗さっぱり終わらせて、心新たに新年を迎えたいものです。 さてさて、今日のAdvent Calenderでは原稿執筆のタスクをBacklogで管理するためのTipsをご紹介したいと思います。原稿を書くことが多い、または編集することが多い方に向けた課題管理手法になっておりますので、どうぞご覧ください。 Backlogで原稿管理とは？ 私は

第2回 #JBUG @東京 「俺みたいになるな！Backlogのアンチパターン」の盛り上がりっぷりをレポート！ ヌーラバーのMIHOです！2017年9月29日にBacklog ユーザーグループ「 JBUG (ジェイバグ：Japan Backlog User Group) 」の第2回目のミートアップが東京で開催！「 JBUG Tokyo #2  -俺みたいになるな！Backlogのアンチパターン-」というテーマで各人各様のしくじり談が共有されました。 みんなでBacklogの「b」ポーズ！ 当日の空気を感じたい！そんなあなたはtogetterをチェック 今回も、JBUG運営の中核を担っているBacklogユーザーの ジョージさん が、すでにtogetterのまとめを作成してくださっています。「レポートブログよりもTwitterのまとめを見たい！」そんなあなたはぜひチェックしてくださいね。 今

ようこそ、サル先生のGit入門へ。 Gitをつかってバージョン管理ができるようになるために一緒に勉強していきましょう！ コースは4つ。Git初心者の方は「入門編」からどうぞ。Gitを使った事がある方は「発展編」がおすすめです。さらに「プルリクエスト編」では、コードレビューする文化をチームに根付かせましょう。 「あれ？何だっけ…？」という時は「逆引きGit」で調べて見てくださいね。