Redmine on Fargate でサーバーレスチケット駆動開発 - Qiita
この記事について 「AWS & Game Advent Calendar 2020」3日目はゲーム開発に役立つコンテナ技術についてご紹介します。 大規模なゲーム開発においてはプロジェクト管理するツールとして Redmine というソフトウェアを利用される方は数多くいらっしゃいます。ゲームを開発する過程では頻繁に変更が発生するため、その作業工程を管理し、往々にして人数が膨れ上がりがちなプロジェクトメンバーに最新の状況をシェアする必要があります。 デバッグ時に発見されたバグはチケットの形で一覧化され、1つ1つを作業として割り振っていくチケット駆動開発のスタイルはアジャイル開発と相性もよく、多くのゲーム開発会社で取られている開発スタイルとなります。 ゲーム開発において身近な存在である Redmine ですが、下手をするとプロジェクト毎にサーバーが乱立しがちとなり、その構築や運用のための工数が気付
redmine-japan発表資料
Step Functions EC2 Lambda Aurora CodeBuild CodeCommit CodePipeline CloudFormation S3 S3 Glacier CloudWatch SNS SQS Athena Kinesis Data Firehose AppSync Elastic Container Registry Application Auto Scaling CloudTrail Systems Manager API Gateway Amplify Secrets Manager AWS WAF Fargate ECS ELB Route53 DynamoDB RDS https://github.com/redmica/redmica_s3 db: name: [db_name] user: [user_name] password: [p
AWS Fargateで並行処理をした話
RailsのDB作成とマイグレーションを複数サイトで同時実行しました。 AWSのサービスを利用すると簡単に実装できました。 Fargate最高！ 吉岡です。11月に開催されるRubyWorld Conferenceに登壇することが決まりました。弊社が提供する「Redmine」のクラウドサービス「My Redmine」のインフラストラクチャーを、Rubyと最新のクラウド技術を活用した構成へと再構築したことについて発表します。ぜひ会場までお越しください！ さて、今日のブログはAWSのFargateを利用して、RailsのDB作成とマイグレーションを複数サイトで同時実行したことについての話です。 目的 AWSのFargateというサービスを利用して、複数のサイト（複数のDB）に対して同時にバッチ処理を実行します。 今回はサンプルとして rails db:create と rails db:mig
林業のタスク管理をRedmineでやる話｜株式会社百森
こんにちは！百森代表の田畑です。今日もオシゴト感の強いお話です。ブランコや秘密基地に類する話も徐々にネタを貯めておりますので、辛抱強く待って頂ければ幸いです。 ※Redmine.tokyoという勉強会で発表しました！（2021/11/27） 概要株式会社百森では、業務の効率化を推進しています。今回の記事では、その初段階として行っているタスクの見える化・進捗管理について、もがきながらも実現していることをまとめました。 ※なお、タイトルを「林業の」としていますが、百森は業界的には特殊です。自治体から委託を受け、所有者交渉・調査設計・補助金申請、施業発注・現場監督を行う業態なので、ニッチであることは予めご了承ください。 昔はこうでした社内では「口伝」と呼んでいますが、これまで作業手順などは口承文学として伝えられていました。 計算結果や、補助金等で必要になる外部とのやり取りという、成果文書の記録は
Redmine を docker-compose で秒殺起動する - らくがきちょう
「手軽に Redmine を試したい！」という場合は docker-compose を利用するのが便利です。 docker-compose で Redmine 環境を用意するには、まず以下の内容で docker-compose.yml ファイルを新規作成します。 今回は CentOS 7.2 を利用しましたが、docker / docker-compose さえ動作すれば、あまり環境差を意識する必要は無いと思われます。 尚、CentOS へ docker と docker-compose をインストールする手順は、やや古いメモですが概ね CentOS7 に Docker ＆ Docker Compose をインストールする から変更ありません (docker-compose のバージョンだけ、新しくした方が好ましいと思われます)。 version: '3.7' services: redm
Itamae | Node Attributes #devops #itamae - Qiita
概要 プロビジョニングツール Itamae Node Attributes について。 json ファイルで定義した Node Attributes を利用して、 レシピの内容を動的に変更して、柔軟性を高めることが出来ます。 例えば、version指定を Node Attributes にすることで、 別バージョンを指定するだけのレシピを何度も作成せずに、 一つのレシピで管理出来ます。 前提 下記記事で作成した resource を流用します。 resource plugin で 板前へのトイレ操作をプラグイン化します toilet はインストール済みとします 試行 レシピを作成 require 'itamae/plugin/resource/toilet' node[:toilets].each do |t| t[:text] toilet t[:text] do filters t[:
ItamaeでNode Attributesに環境変数を使えるようになるGem - Qiita
(2014/12/30 binstubsを使うように修正しました) (2015/5/26 独自コマンドitamae-envを使うように修正しました) はじめに Itamaeで、 パスワードとかレシピで設定したいけどレポジトリにはいれたくないなー ChefのData Bagほどのものはいらないなー 環境変数使いたいなー けどレシピにはENV["hoge"]じゃなくてnode["hogehoge"]って書けた方がいいなー つまりNode Attributesで環境変数指定すればnode["hogehoge"]として使えるようにしてほしい！ っていう感じのitamae-node_envというGemを作りました。 使い方 Gemfileにgem 'itamae-node_env'を追加してbundle install Node Attributesには次のように記述。
Gitで特定のディレクトリだけcloneする方法 - Qiita
これで指定したディレクトリのみがリポジトリにある状態になったかと思います。 普通にgit pullするだけでもいけそうな気がする 補足 branchを変更したい場合 複数branchがあったとして、git branchをしても git read-tree -m -u HEADを実行した時のbranchしか表示されない。 なので.git/configからbranchを書き換える必要がある。 [branch "master"] remote = origin merge = refs/heads/master こんな感じで書いてある箇所があるので、このケースであればmasterと書いてある箇所を書き換えれば良い。 こんなことをしなくても git branch --set-upstream-to=origin/ブランチ名 ブランチ名 これでブランチが追加される。 それでもbranchが表示されな
Itamae で Redmine 環境 - 続けたい日記
とりあえずできた。 参考にしたものをつなぎ合わせただけだけど。 また、itamae の便利な plugin は基本使わないことにして、コードをコピっただけにした。 後で見てわけわかんなくなりそうだったので。 追記: postgesql の起動タイミングを間違っていたので修正。 再追記: さらに間違えてたので修正。また、Postfix も ipv6 無効対応をした。他にもあるかもしれないし、そもそも無効にしなくてもいいのでは・・・と思ってきた。 参考 rbenv qiita.com ほぼ丸パクリさせていただいた SELINUX 無効 github.com disabled のところ丸パクリさせていただいた IPv6 無効 FAQ/CentOS7 - CentOS Wiki IPv6 は使わないが、敢えて無効にする必要ないと思っていたが、 Redmine から PostgreSQL に接続する
RedmineをAWS無料枠に5分で用意して10分で自動バックアップできるようになる - Qiita
はじめに Redmineすごく便利です。やる気が出ないときでもチケットの一覧として並んでいて、それをこなして行くと段々とやる気がでてきます。 またここ最近になってAWSを使い始めたのですがそのお手軽さに感動しています。 ということで今までは自前のサーバでRedmineを運用していましたが、AWSでRedmineを立ててみました。 自分用のメモとしつつ、次回同じサーバを立てるときに5分で構築、10分でバックアップという目標を達成できる用にメモします。 BitnamiのAMIをつかってEC2にインストール 全体の流れは次の通りです。 EC2インスタンスの作成画面へ行く AMIからインスタンスを選択する 作成が完了するのを待つ 管理者用のパスワードを確認する IPアドレスを確認して接続する 完了！ 個人的にあまりAWSには慣れていないので順に追って説明します。 AWSコンソールからEC2を選び、
タスク管理を破綻させないためのTips 5選 | Backlogブログ
仕様や画面は現行バージョンと異なる可能性があります。 Backlogの最新版についてはこちらからご確認ください。 突然ですがあなたのチームはタスク管理がうまくできていますか？ チームで仕事をしていく上で発生するタスクを、プロジェクト管理ツールやタスク管理ツールで管理することは一般的になってきています。 ツールを使わない場合と比較して、タスクが見える化され、状態や期限日、担当者が明確になり、「タスク管理ツールなしの働き方には戻れない！」という方も多いのではないかと思います。 一方で、タスク管理ツールを導入してはみたものの、管理が破綻してしまい、導入以前のやり方に戻ってしまったという声もよく聞きます。 タスク管理ツールは「導入すればすべてを自動的に解決してくれる夢のツール」ではありません。チームの構成やツールの目的、管理の状況にあわせて、適切な運用を行う必要があります。 本記事では、「タスク管
WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる - プログラマの思索
WBSの作り方は組織構造に依存するという記事がとても参考になったのでメモ。 【参考】 ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から ＷＢＳはコスト見積の基準を規定する : タイム・コンサルタントの日誌から 【1】ガントチャート初心者からよく聞かれる質問は、「WBSは工程単位に作った方がいいですか？それとも機能単位に作った方がいいですか？」だ。 話を聞くと、工程単位にチケットを作ってみると、実際の開発フローに合っていない感触があり、途中で、機能単位にチケットを作り直す時が多いらしい。 WBSの作成方法は、工程単位と機能単位のどちらが正しいのだろうか？ (引用開始) さて、３つの機能モジュール×３段階の作業プロセスだから、合計９個のアクティビティからなるプロジェクトである。 これをＷＢＳに構成するとき、二種類の表現が考えられる（ＩＴ系の仕事になじみのない人は、「シス
RedmineでCSIRTのインシデント管理
リスト型としては リスト と、 キー・バリューリスト の2種類ありますが、リスト型を選択しました。 キー・バリューリストは値にリスト選択肢文字が割り当てられるため、選択肢文字の設定を変更すると既に登録済みのチケットの内容も変更されます。 とても便利な機能ですが、インシデント管理ではそれぞれのチケットは内容を変更せず、記録として残すべき対象と考えられます。 今回はあえてリスト型を採用しています。 設定例：情報源 設定例：事象経過 カスタムフィールド作成画面で対象となるトラッカーとプロジェクトにチェックを入れることで利用可能になります。 表示フィールドのカスタマイズ 画面上に不必要なものが表示されていると操作者は混乱してしまいます。これらを整理します。 まずトラッカーとワークフローで不必要なフィールドを消しましょう。 トラッカー 使用するトラッカーにて標準フィールドの項目から使用しないフィール
wikiのコードとかテーブルをリストに反映する方法 - アルパカDiary Pro
Tips的な話。 失敗例 Redmineのwiki記法で、リストの下にpreタグとか表とか入れたい時 普通に記述するとうまくいきませんよね… wikiテキスト * リスト１ ** リスト２ サンプルコードはこちら <pre> #!/usr/bin/perl print "Hello World!!\n"; </pre> *** リスト３ 一覧表です |ほげほげ|ふがふが| |ふげふげ|ほがほが| イメージ なんじゃこりゃぁ〜！ 成功例 上記のテキストをちょっと変えるだけでOKです。 それはpreタグや表タグの前に半角スペースを１つ挿入するだけ！ wikiテキスト * リスト１ ** リスト２ サンプルコードはこちら <pre> #!/usr/bin/perl print "Hello World!!\n"; </pre> *** リスト３ 一覧表です |ほげほげ|ふがふが| |ふげふげ|ほ
チケット同士の関連づけ
Redmine.JP Blog オープンソースのプロジェクト管理ソフトウェアRedmineに関するニュースや、より活用するためのtipsなどを掲載します Redmineにはチケット同士を関連づける機能があります。チケットを相互に関連づけることにより、チケットに記述された作業の前後関係を示したり、相互に関連する作業をわかりやすく示したりすることができます。 関係の種類 Redmineで設定できるチケット間の関係は次の通りです。それぞれの関係の詳細は後述します。 関係している(related to) 重複している(duplicates) ブロックしている(blocks) 先行する(precedes) 後続する(follows) 関係の設定 登録済みのチケット表示画面の「関連するチケット」で関係を設定することができます。 関係の方向 Redmineのチケット間の関係には方向があります。 関係の追
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
第18回Redmine大阪の見所～「チケット管理システムによるソフトウェア開発支援と今後の課題～気象庁のRedmine利用事例報告」 - プログラマの思索
第18回Redmine大阪の見所～「チケット管理システムによるソフトウェア開発支援と今後の課題～気象庁のRedmine利用事例報告」 来年2月3日に開催予定の第66回 SEA関西プロセス分科会＆第18回 Redmine大阪の見所を書いておく。 【参考】 第66回 SEA関西プロセス分科会＆第18回 Redmine大阪 - connpass 気象庁の数値予報課におけるRedmine利用事例: プログラマの思索 【1】（引用開始） テーマ～「チケット管理システムによるソフトウェア開発支援と今後の課題」 今回の勉強会のメインセッションでは、気象庁の担当者の方にRedmineやGit等によるソフトウェア開発支援の事例報告を講演して頂きます。 気象庁｜数値予報課報告・別冊 第63号（平成28年度） 数値予報モデル開発のための基盤整備および開発管理 気象庁におけるソフトウェア開発プロセスの事例で興味深
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://2019.rubyworld-conf.org/files/A-3.pdf
VagrantとItamaeでAmazon Linuxを起動してRuby on Railsの開発環境を整える | Playful IT