web-dev-qa-db-ja.com

小さなチームでDjango）を使用したWeb開発のヒント/プロセス

私たちはDjangoを使用してWebアプリを開発しており、3〜4人のプログラマーからなる小さなチームです。UIやバックエンドを行う人もいます。ヒントとここの人々からの提案これは私たちの現在の設定です：

  1. SCMツールとして Git を使用し、 この分岐モデル をフォローしています。
  2. 私たちはあなたのスタイルガイドのために PEP8 に従っています。
  3. アジャイル はソフトウェア開発方法論であり、そのために Jira を使用しています。
  4. ドキュメントにはJira用の Confluence プラグインを使用しており、 PyDocs をConfluenceにダンプするスクリプトを作成します。
  5. サンドボックス化に virtualenv を使用しています
  6. 使用しています zc.buildout 構築用

これは私が頭のてっぺんから考えることができるものです。他の提案/ヒントは大歓迎です。かなり良いセットアップができていると思いますが、もっとできると確信しています。

web-developmentpythondjangoworkflows
2
Mridang Agarwalla

基本的に、個人的にもチーム環境でも、Django/Pythonワークフローの最適化に関する小さな本を書くことができます。簡単なポイントをいくつかリストアップしてみます。

  • 1-5は問題ありません、それはまさにあなたが始めるべきポイントです
  • コミュニティは全体として、ビルドアウトからpipおよびpipに関連する要件ファイルの使用を完全に避けています。
  • Pipを補完するものとして、bootstrap.shを呼び出すsetup.pyスクリプトをプロジェクトに保持します。これにより、プロジェクト全体がきちんとパッケージ化され、新しいサーバーへのインストールが非常に簡単になります。
  • 継続的インテグレーション/テスト/デプロイメントにJenkinsのようなものを使用することを検討してください
  • これをリンクした優れたブランチモデルに結び付けるには、基本的に、コミット後のフックでmasterブランチへの変更をチェックし、ビルドする時期が来たことをJenkinsに通知できます。 （または、Jenkinsに中央のgitリポジトリを毎分ポーリングさせるなど）。
  • Jenkinsビルドが成功すると（すべてのテストに合格し、他の基準が必要な場合）、ステージングサーバーに自動デプロイされます（ステージングサーバーがあることを願っています）。
  • 展開プロセスにFabricを使用します（ステージングと本番環境の両方に）。ファブリックは、すべてPythonのssh/ftp/etcコマンドのやや高レベルのラッパーであり、サーバーの更新を簡単にします。私がしているのはfab prod deployと入力するだけで、私が所有するすべての本番マシンは、私のサイトの最新バージョンに完全に自動的に更新されます。
  • サーバーの監視は、Nagios、Graphite、Sentry（a Django app）、およびOverseer（another Django app））の健全な組み合わせを使用して実行できます。

それは始めるのに良い場所であるはずです。さらにアドバイスが必要な場合は、Disqus（世界で最大のDjangoアプリ））で開発者から提供されたプレゼンテーションを調べることを強くお勧めします。彼らはおそらくワークフローの最適化とスケーリングについてより多くのことを知っています。私が出会った他の誰か。

3
Pewpewarrows

この プレゼンテーション は、python/Djangoチーム：

  • 自動テスト（Django組み込み）
  • 継続的インテグレーション（Jenkins、Django-jenkins）
  • すべてのものを測定します（歩哨、statsd +グラファイト、新しい遺物）
  • スクリプトデータベース（南）
  • スクリプト展開（ファブリック）
  • 構成管理（puppet/chef）
  • 仮想化開発（Vagrant）
  • テスト分離（テストデコレータ、テストランナーのカスタマイズ）

これに私は追加します：

  • 依存関係にはpipを使用してください。
  • メインブランチのゲートキーパーを用意して、すべてのテストに合格しなかった場合にコードをマージできないようにします。
  • 開発中は、できるだけ頻繁にテストを実行する必要があります。したがって、できるだけ速くするか（つまり、テストにsqliteを使用する）、少なくとも低速と高速に分割します。
1
barracel

実際、私は 分岐モデル がGitでの作業にそれほど適しているとは確信していません。以前に使用したもの（CVSNT）に似ていたので、私はかつて分岐モデルに興奮していました。しかし、それは（一種の）Gitのアイデアに反します。それは物事を必要以上に複雑にします。 コミットポイントは、ブランチよりもGitで重要です。 branchを、ブランチの最後のコミットポイントへのポインタと考えると、より明確になります。

しかし、それはあなたの意見ではないかもしれません。とにかく、いつでも分岐モデルを導入または終了できるので、選択したモデルから始めることができ、何も失うことはほとんどありません。

スコット・チャコンの Pro Git の本、第3章GitBranchingを読むことをお勧めします。

0
pepr