2021年3月31日~30に開催されたCEDEC+KYUSHU 2020 ONLINEでの発表資料です。
![成功したチームと成功しなかったチーム 20160608](https://cdn-ak-scissors.b.st-hatena.com/image/square/c445641d100d5df5f8eca0d59067b0e41b01565d/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F20160608-160613150200-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
2021年3月31日~30に開催されたCEDEC+KYUSHU 2020 ONLINEでの発表資料です。
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール(Hg、Bzr など)にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ブクブクGitGitHub Protected branches and required status checks もうお済みですか!? 9月4日のことですがgithubより以下の機能がリリースされています。 特定ブランチへのforce pushを無効する 特定ブランチへのマージ時にステータスチェックを必須にする(CIと連携している場合は、テストが通るまでマージできないようにできる) これを実施することで、ある日新人が謎の空のコミットをmasterブランチにforce pushして来たり、ある日途中からJOINした人がpull reqもせずにdevelopブランチに謎コミットをforce pushして来たり、ある日とあるOSSで間違えて一ヶ月前のローカルレポジト
はじめに 初心者エンジニアのあなたは、 **先輩エンジニアに「進捗どうなった?」や「なんでこの作業にこんな時間かかってるの?」**といったことを言われたことはありませんか? また、 作業見積もりやタスク分解をちゃんと行なわないで、いきなりコードを書き始めているということはありませんか? 勝手にコードを書き始めて、ほとんど手戻りになって1からコードを書き直しになるという経験もあるかと思います。 僕は徹底的に仕事のやり方を叩きこまれましたが、周りの話を聞いていると、こういったことができていない人もいるのかなと思い書こうと思った次第です。 またエンジニア向けには書いていますが、どんな仕事にも普遍的に使える考え方だと思っているので参考になれば幸いです。 アジェンダ 以下のとおりです。どこから読んでもらっても大丈夫ですが、上から読んでいったほうが流れが分かりやすいと思います。 ツールはGithub,
2015-10-16 イカしたエンジニアになるためのイカしたコミットメッセージ Git 今お仕事させていただいている会社で、以前 【コミッター登壇】プログラマーのための「Rubyの世界」 - connpass で登壇された @idesaku さんとも一緒に働かせていただいてて、今日ありがたいことにマンツーマン(死語?)でgitのコミットメッセージについて講義をしていただいて、それがめちゃめちゃよかったのでブログに残しておこうと思います😊 commitメッセージに関する記事などを以前色んな人が書いてるのを見た気がしますが、個人的な経験として今日得られたのがインパクト強かったので、多少被ったりはしているかもしれませんが、そこらへんはスルーしてくださいmm 経緯 僕のPull Requestに付くコメントが毎回コード自体というよりは commit に関することばかり 「このコミットメッセージは
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。(書く順番が逆っぽい) 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
Jack Wallen (Special to TechRepublic) 翻訳校正: 石橋啓一郎 2015-04-09 06:30 生産性を向上するためのツールは、この5年間で劇的に変わった。かつてよく使われていたスタンドアロンのアプリやクライアント・サーバ型のアプリの多くは使われなくなった。今では、ビジネスのスピードはウェブで決まる。ウェブは、企業が抱えるタスクのほとんどを支えられるようになっている。ローカルにインストールされたクライアントアプリからウェブベースのアプリに移行するには、IT部門が抱えるユーザーの仕事のやり方を一新する必要がある。そのため、選択するウェブベースの生産性向上ツールについては十分な検討が必要だ。 信じられないかもしれないが、これらのツールの多くは、従来使われていたものよりもはるかに費用対効果が高い。さらに、信頼性も高く、従業員がはるかに高い生産性を発揮できるよ
こんにちは、虎塚です。 先日、git-flowをテーマに社内勉強会を行いました。講師役は、AWSチームの都元さんにお願いしました。 クラスメソッドではお客様向けにクラスメソッド・メンバーズというサービスを運営しています。このサービスの会員向けポータルサイトの開発で、Gitとgit-flowを採用しています。そこで、メイン開発者である都元さんにgit-flowの概要を話してもらって、皆で聞こうということになりました。 いつもはAWSコンサルティング部のメンバーで実施している勉強会ですが、今回はテーマが開発寄りなので、AWSソリューション部の人たちにも参加してもらいました。AWSソリューション部は、システム開発を中心に行っている部署です。 上は秋葉原オフィスの会場です。札幌オフィス、上越オフィス、リモートワークのメンバーも、Googleハングアウトで接続して開催しました。 それでは、勉強会の内
あなたのチームは、エンジニアが輝いてますか!? そもそも、僕らエンジニアって世の中をハックして、人を幸せにすることのできる 最高にCOOLでカッコイイ職業じゃないですか。 僕はそんなCOOLでイケてるSuperハッカーチームを作りたいと思って日々のシゴトに取り組んでいます。 で僕たちが思うことは、やっぱり最高の仕事をしてお客様やユーザの方に本当に喜んでもらいたいし、こんなカッコイイ仕事したぞ!って気持ちをチームみんなで分かち合いたい。 今日は、そんな最高な仕事をするために、僕たちが最近チームで使っている合言葉を紹介します!! 本当たった一言のシンプルな言葉なんですが、これは技術者のことをリスペクトして、 理解していない人は分からないんだろうなって思う言葉です。 特に、プロジェクトマネージャとか、開発チームを持っている人には是非、理解して使ってほしいと思います。 ■ 合言葉が必要になるような
Issue管理システムを使っている開発現場では同僚の書いたチケットに悩まされる以下の様な光景が良く見られます。 事例1「何の目的で作られたのか分からないチケット」 ソースレビューを振られたのでチケットを見てみたら、何を変更したいかは分かるけどこの変更がどういう意味があるのか分からないケース 担当者の対応 作業したメンバーの席まで歩いて行って 「ねーねーこれさー、何のために作ったの?」 「あーそれはですね、まず○○という話がありまして、それで…」 (背景から説明されて15分経過) 事例2「ソースを全部読まないと何を変更したか分からないチケット」 ソースレビューを振られたのでチケットを見てみたら10コミットぐらい入れてあるけどチケットの説明が簡素過ぎて何の仕様をどう変更したか(もしくは新規に作ったか)がソースの差分を全部読み込まないと分からないケース 担当者の対応 作業したメンバーの席まで歩い
こんにちは、id:shiba_yu36です。先日開催された「GitHub Kaigi」にて、はてなブログチームでのGitHubを利用した開発フローについて、「はてなブログチームの開発フローとGitHub」というタイトルで発表しました。 資料はこちらです。 はてなブログチームの開発フローとGitHub // Speaker Deck はてなブログチームでは日々開発効率が上がるよう、開発フローの改善をしています。そこで今回の発表では、はてなブログチームの開発フローで、「タスク管理」、「レビュー」、「リリース」の3つのトピックで、実際に起こった問題とそれをGitHubなどを利用してどのように解決してきたかについて具体的に紹介しました。 1つ目のタスク管理というトピックでは、Redmineなどのタスク管理ツールとGitHubを併用している時の問題や、GitHubのIssuesのみタスク管理に利用し
morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く