バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
The problem with Git flow
The problem with Git flow Learn why Git flow complicates the lifecycle and discover an alternative to streamline development. Sometimes, you can have too much of a good thing. That’s certainly true with Git flow, a well-known software development workflow that offers several options but can bog down users. We developed GitLab Flow as the solution to eliminate messy complexity and streamline the de
初心者が先輩からもらったワークフローに関する超初級フィードバックまとめ（IP） - Qiita
プロジェクトのルールや規則はチームによって異なると思いますが、ここでは入門者がプロジェクトに関わっていく上でもらった超初級なフィードバックを備忘録としてまとめておきたいと思います。随時更新予定です。 ワークフロー全般に関するフィードバック プルリクをするときは必ずUpdate from masterをする。（2016/12/26 Mon） プルリク前にPC/SP(iphone5 , 6 , 6plus)それぞれの環境で正しく動作しているか確認すること（2016/12/26 Mon） ブランチの命名規則を覚える（2016/12/26 Mon） プルリクをするときは必ずUpdate from masterをする。 自分がコードを書いてる間に他の人もコードを書いてアップデートしているから、それを自分のソースコードにも反映してプルリクをすること。最悪の場合、そのままmasterにsyncしてdep
Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
