質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.51%
FTP

FTP(File Transfer Protocol)は、ネットワークでのファイル転送を行うための通信プロトコルの1つである。

Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

Webサーバー

Webサーバーとは、HTTPリクエストに応じて、クライアントに情報を提供するシステムです。

GitHub

GitHubは、Gitバージョン管理システムを利用したソフトウェア開発向けの共有ウェブサービスです。GitHub商用プランおよびオープンソースプロジェクト向けの無料アカウントを提供しています。

AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

Q&A

解決済

4回答

1495閲覧

Gitでのチーム開発時の構成

penta0205

総合スコア3

FTP

FTP(File Transfer Protocol)は、ネットワークでのファイル転送を行うための通信プロトコルの1つである。

Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

Webサーバー

Webサーバーとは、HTTPリクエストに応じて、クライアントに情報を提供するシステムです。

GitHub

GitHubは、Gitバージョン管理システムを利用したソフトウェア開発向けの共有ウェブサービスです。GitHub商用プランおよびオープンソースプロジェクト向けの無料アカウントを提供しています。

AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

0グッド

6クリップ

投稿2020/08/13 08:04

前提・実現したいこと

現在複数の社内システム(WEBアプリケーション)の運用開発を10人程のチームでおこなっております。
FTPでの開発を行ってますが、開発用のサーバーと本番サーバーをAWSに移行するにあたりGitを利用してのチーム開発へ変更したくどのような構成にするべきか教えて頂きたいです。

現在の開発の流れとしては、
1.共有ファイル用のローカルサーバーにあるソースをそれぞれが編集
2.共有ファイルをFTPでテスト用のローカルサーバーにアップロード
3.テストサイト上でデバッグなどを行う
4.問題なければGMOの専用サーバー上から変更ファイルをダウンロードし差分を確認してから、
5.専用サーバー上にFTPでアップロードし本番公開を行う。

という風になってます。

また、AWSは開発用と本番用で2つ契約してます。

試したこと

Gitについてはまるっきりの初心者で経験もありませんが、Git利用にあたり一通り調べてgitやgithubの基本的な概念なら把握できているかと思います。
各自のローカルリポジトリからリモートリポジトリへpushしてそれを本番公開という流れはなんとなくわかるのですが、
おそらく開発用と本番用とサーバーがわかれているので、githubにローカルからpushしその内容を開発用のサーバーにデプロイ?する。
問題なければ本番にデプロイという流れなのかなと考えています。

githubは使用しないでサーバー上にリモートリポジトリを作るやり方などもあるのでしょうが、どの方法が一般的なのか、またそれぞれの方法にどのようなメリットデメリットがあるのかがわかりませんでした。

まるっきり見当違いのことを言っていたら申し訳ないです。
よろしくお願いします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

ベストアンサー

いろんなやり方があって究極的には正解はないのですが、ベストプラクティスに近いものはあります。

おそらく開発用と本番用とサーバーがわかれているので、githubにローカルからpushしその内容を開発用のサーバーにデプロイ?する。

問題なければ本番にデプロイという流れなのかなと考えています

大まかな流れとしては問題ないと思います。
ただ、できれば開発、ステージング、本番と3つは環境があったほうがいいでしょう。
開発環境は本当に各メンバーの開発用で、ローカルで開発したものを動作確認したり直接その上で開発をしたりするための、比較的実際の動作環境に近めの環境(同じ環境を用意できるならベスト)
ステージングは複数人が開発したソースを合わせた上で、本番環境同様の構成でテストや動作確認をするための環境
みたいな感じで分けるイメージです。
これもざっくりな分け方なので、絶対ではないです。

各自のローカルリポジトリからリモートリポジトリへpush

この辺は説明の必要がないかもしれませんが念の為。
同じリポジトリの同じブランチに無条件にpushすると同じ箇所を変更したときに問題が発生します(コンフリクト)
なので、基本的には作業ごとにブランチを切って、プルリクエストでレビューを行った上で承認されたらデプロイ用のブランチにマージする、という流れにすると良いでしょう。
差分はGitHubのプルリクエスト上で確認します。

デプロイするブランチは予め決めておきます。
開発環境と本番環境で専用のデプロイブランチを用意しておくのもいいですし、開発環境でテストが済んだことを何かで保証できるならデプロイ用ブランチを一つだけ用意しておくでもいいので、このへんはルールで決めることです。

デプロイの方法についてはソースによって変わります。
最も単純な手段はサーバ上でgit clone/pullすることですが、ただ配置するだけでは動かないケースは多々あります。
配置後に何かしらのコマンド実行が必要になったり、ビルドが必要だったり。
それらすべてを手動でやることもできますが、そのへんは少しずつ自動化するといいでしょう。
デプロイはブランチやコミット、タグを指定した上で自動でできるようにしておくと、実環境への反映がスムーズに行なえて開発効率が大きく上がるでしょう。

いきなりここまでやるのは大変ですが、CI/CDという言葉について調べてみるといいかなと。
それについて追加で説明するのはあまりにも大変なので一旦は割愛します。
CI/CD とは
CI/CDのエキスパートが解説:CI/CDとは何か? なぜ今、必要とされるのか?

GitHubならGitHub Actionsを使った方法もありますし、AWSのサービスを使うならCodeBuild/CodeDeployやそれらをまとめたCodePipelineを使う方法もあります。
古くからだとJenkinsを使う方法もありますね。
CircleCIみたいな、そのためのサービスみたいなものもあります。

githubは使用しないでサーバー上にリモートリポジトリを作るやり方などもある

できなくはないですが、それをやることはほぼないです。自分も実際には全く見たことがありません。
※GitHubをサーバ上で動かす、GitHubエンタープライズというサービスならありますが…。
GitHubがデファクトスタンダードなので、何もわからなければとりあえずGitHubを使うことをお勧めします。
あと、一応同様のgitリポジトリ管理サービスは他にもいくつかあります。
GitLabやBitBucket、AWSならCodeCommitなど。
ただ、全くgitの経験がないなら素直にスタンダードであるGitHubを使っておいたほうが良いかと思います。

また、社内システムならリポジトリを非公開にすることをお忘れなく。
今ならGitHub Organizationも無料で使えるようになったので、自分の会社のOrganizationを作るといいでしょう。
これらはかつては有料プランでしかできませんでしたが、今なら無料でできます。

投稿2020/08/13 08:51

yu_1985

総合スコア7411

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

penta0205

2020/08/14 01:08

とても詳しく回答してくださりありがとうございます。 考え方がそんなに間違っていなかったようで安心しました。 pushをローカルからしたときにテストか本番に自動でデプロイされるように設定すればよいということですかね?CI/CDについても調べてみようと思います。
yu_1985

2020/08/14 05:57

pushでいきなりデプロイされるようにすると、レビューを受けていない(品質を担保されていない)ソースがいきなり環境上に展開されることになります。 開発者が一人で、開発環境に限りそのようにするのであればわからなくもないですが、避けたほうがいいでしょう。 特に本番は品質を担保するということと、デプロイのタイミングをコントロールするという意味でも絶対にpushではなくプルリクエストがマージされた後にデプロイされるようにすることをお勧めします。 デプロイだけを自動化して、タイミングは手動で、というのもアリです。 そのへんはデプロイプロセスの設計次第ですね。
.M.

2020/08/18 04:19

便乗でコメントします。10人ということで中規模以上のシステムだとお察ししますが、まずはgitを使った開発プロセス(ルール)をチーム内でまずは学習する/取り決めるのが良いと思います。少人数(2-4人程度)でも、gitに慣れていなかったりすると、勝手にbranchをmergeされたり、mergeの方向が逆であったり、ローカル環境にあるパスワードファイルを一緒にpushしたり、、、びっくりすることが実際山ほど起きるので。
guest

0

有名な競合製品としてperforceもありますので、それを参考にすると、分散開発環境としてGitがよく見えてきます。bareでもbareでなくても、そのかたの環境ごとに調整すればよいとおもいます。
その時に、あまりにも多くの知識が必要となりますのでスローガンとしては、たくさんある言葉の中から1つを選ばさせていただいております。
わからないことがあれば、こべつに回答しますし、他の方がご回答なさることもあるかとおもいますが、
私の解答で、誤解などがある場合は説明不足の責任として補足回答させていただいております。
スペースを汚してしまい、申し訳ございません。ありがとうございます

投稿2020/08/22 04:25

kokorohamoe

総合スコア190

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

諸般の事情で私だとその構成にしないと思う。
何故その構成を自社で禁止するか?というのは会社ごとの運営方針や他のツールとの依存関係があるために、答えはない。
ただ、リモートとローカルというのは、自分が作業していない方、自分が今作業をしている方という意味合いを持っていて、かりに、自分がリリース用の環境で作業していて、開発用の環境にフィードバックする場合、リモートとローカルの意味が通常のときと逆転する場合がある。
そのため、リリース用のサーバをリモートとした場合、など安全策をとっておかないといけない場合がある。なので言葉をもう少し丁寧に使うとトラブルが増え(誤字訂正 トラブルが減りが本意)、デスマーチが早期解決すると少し思いました。外部からの一読者としてのコメントです。
Gitを扱う場合、いつ、だれが、どのように、なぜ行ったかというのをすべて記録をとりながらおこない、いつでも、その変更を取り消せるというのが、ツールの基本マインドです。それを念頭に入れながら、分散開発環境とはなにか?サーバとはなにか?というところをきちんと勉強すると、まちがいがなく安価にAWSなどに移行できると思いました。
教え過ぎは良くない、聞かれたことのみにこたえよというのが鉄則ですからこういうふうに書かせてください。追加質問は新しいTOPICをお願いします。それがここのルールでない場合は教えて下さい。がんばってね。

投稿2020/08/18 01:10

編集2020/08/18 01:14
kokorohamoe

総合スコア190

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Zuishin

2020/08/22 01:47

ブランチとリポジトリの区別もついてないじゃないですか。「教え過ぎは良くない」ではなく、「教えられない」の間違いでしょう。あなたの知ったかぶりはさすがに目に余ります。
kokorohamoe

2020/08/22 03:59

perforceの業務経験もあります。 セキュリティーチームではセキュリティーの都合で最近でもCVSでした。gitは個人利用などのほうが多いです。 今年の合言葉はDid you believe in the Force of the Power? です。質問があれば個別にお願いします。私のできる範囲で、お答えします。
Zuishin

2020/08/22 04:02 編集

Git を使ったことのある人がベアで作業すると? そんなわけないでしょ。
kokorohamoe

2020/08/22 04:09

※ https://www.perforce.com/ja/ perforce 企業向けバージョン管理システムで、Gitの分散バージョン管理システムの対極をなしてている中央集中管理システムのうち有名なものの方のことです。 補足まで
Zuishin

2020/08/22 04:12

で? あくまでベアで作業すると?
Zuishin

2020/08/22 04:13

Git の話をしてるんだけど Git 知ってる?
Zuishin

2020/08/22 04:15

> Gitを利用してのチーム開発へ変更したくどのような構成にするべきか教えて頂きたいです。 質問にこう書いてあるけど読めるの?
kokorohamoe

2020/08/22 04:17 編集

大変申し訳ございませんが、git にもbareオプションがありますが こちらは専門用語のためbareと区別するとbare であるかnon bareであるかは、大きな違いではない環境で作業しております。私は主に利用者側で、gitの場合はローカルの環境に余裕がある環境の場合が大多数ですので、管理者に指示されたとおりにgit作業を行います。 そのためペア ベアの打ち間違いも考慮し 申し訳ございませんが意味が取れませんでした。
Zuishin

2020/08/22 04:18

こちらがどちらか知らないけど、perforce の話は誰もしてない。日本語読めるようになってから来い。 わけのわからない類推で知らないことを知ったかぶるな。
kokorohamoe

2020/08/22 04:19

> Gitを利用してのチーム開発へ変更したくどのような構成にするべきか教えて頂きたいです。 ですので 今年のスローガンは Did you believe in the Force of the Power? で象徴されると思います。 Forceには映画スタウォーズおよび Perforceという製品もかかっていますので念の為、予備知識として、ご紹介しました。
Zuishin

2020/08/22 04:20

寝言でごまかすのもやめろ。
guest

0

開発用のサーバーと本番サーバーをAWSに移行するにあたり
Gitを利用してのチーム開発へ変更したくどのような構成にするべきか教えて頂きたいです。

githubにローカルからpushしその内容を開発用のサーバーにデプロイ?する。
問題なければ本番にデプロイという流れなのかなと考えています。

以前そのような構成で開発していました

今のワークフローに影響が少ないようなやりやすいところ、
効果の大きいいところから少しずつその構成に近づけていくと良いと思います

投稿2020/08/13 09:00

y_shinoda

総合スコア3272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

penta0205

2020/08/14 01:10

ありがとうございます。 まずはテストサーバーのほうから、徐々にgitへ移行していこうと思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.51%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問