【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
docker で Ctrl-p ２回押し問題 (detach-keys の問題) を解決するには - Qiita
http://qiita.com/YutakakINJO/items/eeb579f75feb50fa18ae で言及されている問題が、もうすでに解決されているのでメモしておく。 問題(再確認) デフォルトでは Ctrl-p は、detachKeys の一部として認識されていて、コンテナにこのキーを送るには、 Ctrl-p を２度押しする必要があった。 解決方法 docker v.1.10.0 から、 detachKeys を変更する機能が実装された。ので、普段使わないキーに、この detachKey を配置してやればよい。 以下のファイルを ~/.docker/config.json に配置する。
デザイン受け渡しのGit運用を再構築。「用語の壁」を乗り越えるための取り組みとは？ | SELECK
〜チームの成長に合わせてGit運用を見直し、デザイナーにまで活用の幅を広げた事例〜 エンジニアには馴染みの深い、「Git」。GitHubなどのサービスの登場により、プログラミング未経験者でも耳にする機会は増えているが、敷居の高さを感じている人も多い。 DMM.comが提供する、モノづくりのためのプラットフォーム「DMM.make」。その開発・運用を担当する株式会社DMM.comラボのDMM.makeチームでは、デザイナーとエンジニアの「デザイン取り込み」作業に課題を抱えていた。 どのデザインがどの案件に対応しているのか分からず、確認作業が発生するなど必要以上に時間がかかる状態だったという。 その課題を解決するため、デザイナーにGitを浸透させたのが、同社に2015年卒で入社したエンジニアの西岡 景子さん。 Gitに限らず、運用の改善が好きだと語る西岡さんに、デザイナーにまでGit活用を広げ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
