書籍執筆における、継続的なデリバリー - Natural Software
今回の本は3人で書いたこともあり、前回と比べて執筆環境を大きく変えました。 その中の一つに「最新の原稿を、すぐに電子書籍の形で確認できる」環境があります。 専門的に書くと 「Sphinxのドキュメントを、githubにpushすると、JenkinsがビルドしてePubにしてくれる」 ようにしました。もう少し砕くと 「原稿を、インターネット上で共有している場所に置くと、自動で電子書籍の形にしてくれる」 でしょうか。 具体的には、左のようなテキストが、右のような電子書籍に(自動で)なります。 自動的に生成された電子書籍を確認することで、編集者や著者が最新の原稿の内容を確認できるようになっています。 オーム社やオライリー社でやってる制作システムを自前で構築しました、ということです。 より詳細な構築方法については、反響を見て考えようかと思います(アカウント管理やなんかがちょっと手間になりそうなので
Python+FlaskなwebアプリをJenkinsでウイーン - Qiita
(-_-).oO(タイトルは気にしない事、考えるの面倒なんだよ) はじめに Python+FlaskなwebアプリをJenkinsでビルドしまくるようにしたのでそのメモ。 ディレクトリ構成はこんな感じ(見せたくないディレクトリは消してます)。 % tree -d . ├── env (virtual env) ├── project │ ├── app │ ├── conf │ ├── logs │ ├── models │ │ └── mongo │ ├── services │ ├── static │ ├── templates │ ├── tests │ │ ├── app │ │ ├── cover │ │ ├── data │ │ ├── models │ │ │ └── mongo │ │
継続的デリバリーとは何か？
みなさんこんにちは。@ryuzeeです。 継続的デリバリー（Continuous Delivery）の定義を改めて整理してみました。 まず1つめの定義は以下の通りです。 Continuous DeliveryとはリリースのスケジュールをIT部門が握るのではなく、ビジネス部門が握るということだ。 Continuous Deliveryを実装するということは、全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じて、秒とか分の時間で利用者にリリース可能である、ということだ。 Jez Humble Continuous Deliveryとは何か？ユーザーとプロジェクトチーム（顧客やプロダクトオーナーも含む）の間に固いフィードバックループを作ることは、結局のところ、試験的な変更や新し
継続的デリバリーの8つの原則
継続的デリバリーの8つの原則1. ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。このことは2つめの原則にたどり着く。 2. 全てを自動化する！手動のデプロイは決して繰り返し可能で信頼性が高いことには成り得ない。 あなたは繰り返し行う全てのタスクを自動化することについて本気で投資する必要がある。そしてこうすることによって信頼性に繋がっていくのだ。 3. なにか難しかったり苦痛なことがあったら、それを何度もやってみる表面的には、ばかげた話のように聞こえるかもしれない。しかし基本的にこれが意味していることは、苦痛であることを頻繁に行うことは、あなたがそれを改善し、多分自動化する方向に導いてくれるはずだ。そして最終的には苦痛がなくなり容易に行うことができるようになるだろう。 データベースのスキーマをデプロイすることを例にとってみてみよう。もしこれがトリッキー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.jenkins.io/content/python-love-story-virtualenv-and-hudson/
Python multiple versions testing with Jenkins