RE: Git Deployment using existing multiple environments

[Johannes Schindelin]

Hi,

please stop top-posting. It is quite irritating by now. Thank you.

On 2015-09-15 08:50, Sukhwinder Singh wrote:

> Now lets say we set up a repository at github which has the latest
> code (all test code)., Now at each of our own servers we already have
> existing code, that is Test, UAT and Live. For example, first he'll
> pull code from github to our Test Server and then move branches to UAT
> and then to Live. Can it work?

Yes, it can work.

The major problem here will be that you have only a single, central repository 
that every developer has write access to, but you expect only a single trusted 
person to deploy that code via three different stages. That can be tricky, in 
particular if your trusted person is a newbie.

> If it can work then can I please get some some example commands or the 
> procedure to set it up?

Sorry, this feels a bit too much like "could you please do all my work for me?" 
to me. And if I really provide exact commands here, I may even be liable when 
it does not work out in the end? I am not going to do that.

Instead, I will strongly suggest to learn enough about Git to answer those 
quite simple questions ("How do I pull?", "What is a pull?", "How do I update a 
test machine's working directory with the newest branch tip?") yourself. I 
usually recommend https://try.github.io/

> Time is a bit of problem right now or I would have read book suggested by 
> Johannes. I have searched on the internet but couldn't find any similar case.

If I was in your shoes, I would spend the time *now*, rather than quite 
possibly spending 10x as much time later when I have to clean up a mess. In my 
experience, 
what looks like the cheap route (copying commands without understanding them, 
really), invariably turns out to be the most expensive route possible.

In any case, this was as much useful feedback as I had to give to your 
questions.

Ciao,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Git Deployment using existing multiple environments

[Sukhwinder Singh]

Thank you very much for the detailed reply. There is going to be just one 
person who'll manage all the moving of the code. On approval he'll move code 
from one environment to other on our own servers (right now it is being done by 
manual merging). Development team is not that big right now. They'll be 
committing all new code to the git repository we have setup up at github using 
all over test environment code. And the person handling the code at our server 
will move code from one environment to other by USING Git and not by manual 
merge.

Now lets say we set up a repository at github which has the latest code (all 
test code)., Now at each of our own servers we already have existing code, that 
is Test, UAT and Live. For example, first he'll pull code from github to our 
Test Server and then move branches to UAT and then to Live. Can it work? If it 
can work then can I please get some some example commands or the procedure to 
set it up? Time is a bit of problem right now or I would have read book 
suggested by Johannes. I have searched on the internet but couldn't find any 
similar case.

Regards,
Sukhwinder Singh


> From: jacob.kel...@gmail.com
> Date: Mon, 14 Sep 2015 01:32:39 -0700
> Subject: Re: Git Deployment using existing multiple environments
> To: php_programmer_in...@hotmail.com
> CC: johannes.schinde...@gmx.de; git@vger.kernel.org
>
> On Sun, Sep 13, 2015 at 10:55 PM, Sukhwinder Singh
> <php_programmer_in...@hotmail.com> wrote:
>> Thank you for the reply. Let's say I do setup three different repositories 
>> then how can we move work from one repository to the other. For example, 
>> from Test Environment to UAT. If there are any links that you can provide me 
>> that I can check, it'll be great.
>>
>> Regards,
>> Sukhwinder Singh
>>
>
> Generally speaking there are two ways of moving work from one
> repository to another. The first is the "pull" where you request data
> from a remote repository and then merge that data into your own. This
> is what you're doing when you perform a clone, a fetch, or a pull.
> It's what everyone does all the time when working with a local copy of
> a "trusted" remote repository. It can also be done between two
> "trusted" remotes, if your workflow is more distributed. (ie: more
> than one "official" source).
>
> The second form of moving work is the "push" where you upload your
> work into another repository. This is most commonly used when the
> workflow is "centralized". By that I mean there is a single
> authoritative repository. Or when you are moving your own work on a
> local machine into a remotely accessible machine for others to pull
> from.
>
> As Johannes said above, you really need to determine the work flow and
> team style you want before you can really understand the best way to
> setup repositories. For example, if you setup using a distributed
> chain of command, you can have one person be the "maintainer" of each
> given trusted repository. Then, maintainers can pull (or
> equivalent-ly, pull-request) between each other. This is generally how
> a project would work when using github. One person is the maintainer,
> then a developer "forks" the project, makes some changes, then
> requests that the maintainer pull these changes. The maintainer has
> final say and will perform the final merge in cases of conflict. In
> addition, maintainer is the one who says "this is ok to go into this
> repository".
>
> You can also instead opt to use a single centralized repository. Thus,
> developers would work on code and get it ready to submit, and then
> simply perform a push. If the push requires a merge git will tell the
> user to update. There are many tools such as server side hooks in
> order to enforce various behaviors.
>
> This flow generally doesn't use sole maintainers, as each developer
> has access to push directly. It may work well for smaller teams or for
> dedicated teams who don't change developers often.
>
> A lot comes down to how your team is structured. Do you have one
> person who's job can be to maintain the repository? Do you have
> several developers who don't want to be the sole owner? Is your team
> willing to function much more distributed?
>
> In the end, it's generally always a good idea to designate at least
> one repository as the "authority" so that everyone knows where to look
> for release tags and other such data.
>
> Myself, I would say that I prefer to use the pull-request model so
> that code gets more review, as "push" based models tend not to do
> review. (Exception: Gerrit, but this uses "git push" on the command
> line to do something very much not like a push)
>
> Regards,
> Jake
  --
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Git Deployment using existing multiple environments

[Sukhwinder Singh]

---
> Date: Tue, 15 Sep 2015 09:48:34 +0200
> From: johannes.schinde...@gmx.de
> To: php_programmer_in...@hotmail.com
> CC: jacob.kel...@gmail.com; git@vger.kernel.org
> Subject: RE: Git Deployment using existing multiple environments
>
> Hi,
>
> please stop top-posting. It is quite irritating by now. Thank you.

Sorry about that. Haven't used mailing lists since almost a decade. Forgot how 
it should be used.

Thank you very much everyone for replying.  The advice from everyone is much 
appreciated.

Regards,
Sukhwinder Singh
  --
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git Deployment using existing multiple environments

[Jacob Keller]

On Sun, Sep 13, 2015 at 10:55 PM, Sukhwinder Singh
 wrote:
> Thank you for the reply. Let's say I do setup three different repositories 
> then how can we move work from one repository to the other. For example, from 
> Test Environment to UAT. If there are any links that you can provide me that 
> I can check, it'll be great.
>
> Regards,
> Sukhwinder Singh
>

Generally speaking there are two ways of moving work from one
repository to another. The first is the "pull" where you request data
from a remote repository and then merge that data into your own. This
is what you're doing when you perform a clone, a fetch, or a pull.
It's what everyone does all the time when working with a local copy of
a "trusted" remote repository. It can also be done between two
"trusted" remotes, if your workflow is more distributed. (ie: more
than one "official" source).

The second form of moving work is the "push" where you upload your
work into another repository. This is most commonly used when the
workflow is "centralized". By that I mean there is a single
authoritative repository. Or when you are moving your own work on a
local machine into a remotely accessible machine for others to pull
from.

As Johannes said above, you really need to determine the work flow and
team style you want before you can really understand the best way to
setup repositories. For example, if you setup using a distributed
chain of command, you can have one person be the "maintainer" of each
given trusted repository. Then, maintainers can pull (or
equivalent-ly, pull-request) between each other. This is generally how
a project would work when using github. One person is the maintainer,
then a developer "forks" the project, makes some changes, then
requests that the maintainer pull these changes. The maintainer has
final say and will perform the final merge in cases of conflict. In
addition, maintainer is the one who says "this is ok to go into this
repository".

You can also instead opt to use a single centralized repository. Thus,
developers would work on code and get it ready to submit, and then
simply perform a push. If the push requires a merge git will tell the
user to update. There are many tools such as server side hooks in
order to enforce various behaviors.

This flow generally doesn't use sole maintainers, as each developer
has access to push directly. It may work well for smaller teams or for
dedicated teams who don't change developers often.

A lot comes down to how your team is structured. Do you have one
person who's job can be to maintain the repository? Do you have
several developers who don't want to be the sole owner? Is your team
willing to function much more distributed?

In the end, it's generally always a good idea to designate at least
one repository as the "authority" so that everyone knows where to look
for release tags and other such data.

Myself, I would say that I prefer to use the pull-request model so
that code gets more review, as "push" based models tend not to do
review. (Exception: Gerrit, but this uses "git push" on the command
line to do something very much not like a push)

Regards,
Jake
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Git Deployment using existing multiple environments

[Sukhwinder Singh]

Thank you for the reply. Let's say I do setup three different repositories then 
how can we move work from one repository to the other. For example, from Test 
Environment to UAT. If there are any links that you can provide me that I can 
check, it'll be great. 

Regards,
Sukhwinder Singh


> Date: Sat, 12 Sep 2015 12:55:46 +0200
> From: johannes.schinde...@gmx.de
> To: php_programmer_in...@hotmail.com
> CC: git@vger.kernel.org
> Subject: Re: Git Deployment using existing multiple environments
>
> Hi,
>
> On 2015-09-12 08:31, Sukhwinder Singh wrote:
>
>> We already have 3-4 environments setup on our Windows servers without Git
>> and each environment already has code which is different from each
>> other.
>>
>> There are three environments
>> Live
>> UAT
>> Test (has the latest code)
>>
>>
>> And then developers have their local copies.
>>
>> We write and test the code locally and manually move each point from
>> one environment to other using merging software and test at each
>> environment.
>> Now we want to use git because manually moving the code is a lengthy
>> process. Also as the developers have local copies, it is very
>> difficult to manage code.
>>
>> Code is written locally by the team and then after testing locally it
>> is first merged with "Test" environment code, then "UAT" and then,
>> finally with "Live".
>> So we have two concerns:
>>
>> There is different code already existing on these environments.
>> Testing the code on each environment using the web server.
>>
>> What is the best way to go about it? As I am new to git more details
>> will be helpful, like commands to use.
>
> It seems you are not only looking for commands to use, but for a proper 
> workflow in which Git supports your work best.
>
> The key is to define the roles in your flow first, and then identify the 
> optimal commands.
>
> In your case, I figure that there are three "merge lords" or "merge ladies", 
> one for "Test", one for "UAT", one for "Live". And each of them needs to be 
> notified when changes are ready to be merged, then merge the changes.
>
> If I was walking in your shoes, I would set up four repositories that each 
> are owned by one of the "merge lords/ladies", or the developers, 
> respectively. The code would move from one to the next repository, triggered 
> by a notification, then being pulled into the environment, then tested, and 
> if everything is okay, pushed into the next repository.
>
> (Actually, you could do without the repository corresponding to the "Live" 
> version, but it would be a nice record.)
>
> However, this is just one possible suggestion. I would highly recommend 
> buying and reading the book "Git for Teams", as it has extensive coverage of 
> different work flows, their strengths and their weaknesses.
>
> Ciao,
> Johannes
  --
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git Deployment using existing multiple environments

[Johannes Schindelin]

Hi,

On 2015-09-12 08:31, Sukhwinder Singh wrote:

> We already have 3-4 environments setup on our Windows servers without Git
> and each environment already has code which is different from each
> other.
> 
> There are three environments
> Live
> UAT
> Test (has the latest code)
> 
> 
> And then developers have their local copies.
> 
> We write and test the code locally and manually move each point from
> one environment to other using merging software and test at each
> environment.
> Now we want to use git because manually moving the code is a lengthy
> process. Also as the developers have local copies, it is very
> difficult to manage code.
> 
> Code is written locally by the team and then after testing locally it
> is first merged with "Test" environment code, then "UAT" and then,
> finally with "Live".
> So we have two concerns:
> 
> There is different code already existing on these environments.
> Testing the code on each environment using the web server.
> 
> What is the best way to go about it? As I am new to git more details
> will be helpful, like commands to use.

It seems you are not only looking for commands to use, but for a proper 
workflow in which Git supports your work best.

The key is to define the roles in your flow first, and then identify the 
optimal commands.

In your case, I figure that there are three "merge lords" or "merge ladies", 
one for "Test", one for "UAT", one for "Live". And each of them needs to be 
notified when changes are ready to be merged, then merge the changes.

If I was walking in your shoes, I would set up four repositories that each are 
owned by one of the "merge lords/ladies", or the developers, respectively. The 
code would move from one to the next repository, triggered by a notification, 
then being pulled into the environment, then tested, and if everything is okay, 
pushed into the next repository.

(Actually, you could do without the repository corresponding to the "Live" 
version, but it would be a nice record.)

However, this is just one possible suggestion. I would highly recommend buying 
and reading the book "Git for Teams", as it has extensive coverage of different 
work flows, their strengths and their weaknesses.

Ciao,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html