Discussion: continuous deployment was: Discussion: migrating from Ant to Gradle

[Hans Bakker <ma...@antwebsystems.com>]

Jacopo,

Sorry to react on your comment at the end of your post below.

May i ask you to study continuous deployment? Up to now the trunk was 
always very stable. Once in a while some problems, but they never lasted 
more than a couple of days.

At AntWebsystems we are supporting continuous deployment (expect a 
linkedin post on this) and we upgrade our production OFBiz version every 
month by hand picking a trunk version which we think works. Then this 
version will run on our demo server for one month and when no problems 
will be put in production. This is working fine for the last 3 years.

So what we are doing is upgrading the ofbiz core system every month, 
which a step in the direction of continuous deployment. However, the 
goal is that before any commit is going into trunk it should be tested 
(selenium and junit) and approved by at least another committer (peer 
review)

I would like to know how others think about continuous testing and 
continuous deployment. If you make the master (sorry trunk) branch 
deliberately unstable and not create development branches, you kill the 
continous deployment principle.

You want innovation?
1. Convert to GIT
2. install Gerrit for peer review
3. Install Jenkins for running all tests daily, also run tests for the 
development branches
4. Do not allow any change in the master branch ofbiz system without a 
successful junit or selenium test and peer approval.

then you will have a production ready 'master' branch most of the time 
and the demo server can act as a staging server.

Regards, Hans




On 21/08/14 12:41, Jacopo Cappellato wrote:
> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> This is one reason which would refrain me to jump right now. With of course all the burden and especially the inherent risks of permutation.
>>
>> I think that Pierre's idea of a branch is a reasonable compromise
>>
>> Jacques
> Of course, if we will ever try the switch to Gradle, this would be done in the trunk only, not backported to releases; so the instability period will only affect the trunk.
> This is exactly the purpose of trunk vs release branches.
> The fact that there are persons that use the trunk in production, and that don't want it too change much because this may cause them to work to keep their custom tools/code up-to-date, is a burden that slows down the evolution of OFBiz.
>
> Jacopo

Re: Discussion: continuous deployment was: Discussion: migrating from Ant to Gradle

[Taher Alkhateeb <sl...@gmail.com>]

Hi Jacopo,

One of the ideas we suggest is to introduce gradle alongside ant at the top
level directory (build.gradle next to build.xml) and replace some of the
scripts that currently exist under /tools with tasks and projects in gradle
(e.g. mergefromtrunk.sh). It is also quite trivial to design time-based
tasks which can be called from the continuous integration server (updating
infrastructure, automating workflow, etc ...). We can then start to slowly
replace ant across the project without a sudden full replacement given the
full inter-operability between ant and gradle.

Please let us know how can we be of help if you choose to integrate gradle!
Cheers!

Taher Alkhateeb


On Thu, Aug 21, 2014 at 9:39 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:

> What you describe is (I guess) essentially this:
>
> https://www.atlassian.com/git/workflows#!workflow-gitflow
>
> and I know it (we have projects following this pattern) and it works
> pretty well; this is *not* the workflow that OFBiz community is currently
> implementing. Theres is no right or wrong workflow... it depends on the
> project and requirements.
> The fact that your company is following a different workflow that works
> for you is great but it doesn't mean that the OFBiz community has to act
> accordingly.
> I am wide open to discuss the migration to different workflows and tools
> (like Git) but for now let's stick to what we have and not on what you have
> decided for your company.
>
> Jacopo
>
>
> On Aug 21, 2014, at 8:13 AM, Hans Bakker <ma...@antwebsystems.com>
> wrote:
>
> > Jacopo,
> >
> > Sorry to react on your comment at the end of your post below.
> >
> > May i ask you to study continuous deployment? Up to now the trunk was
> always very stable. Once in a while some problems, but they never lasted
> more than a couple of days.
> >
> > At AntWebsystems we are supporting continuous deployment (expect a
> linkedin post on this) and we upgrade our production OFBiz version every
> month by hand picking a trunk version which we think works. Then this
> version will run on our demo server for one month and when no problems will
> be put in production. This is working fine for the last 3 years.
> >
> > So what we are doing is upgrading the ofbiz core system every month,
> which a step in the direction of continuous deployment. However, the goal
> is that before any commit is going into trunk it should be tested (selenium
> and junit) and approved by at least another committer (peer review)
> >
> > I would like to know how others think about continuous testing and
> continuous deployment. If you make the master (sorry trunk) branch
> deliberately unstable and not create development branches, you kill the
> continous deployment principle.
> >
> > You want innovation?
> > 1. Convert to GIT
> > 2. install Gerrit for peer review
> > 3. Install Jenkins for running all tests daily, also run tests for the
> development branches
> > 4. Do not allow any change in the master branch ofbiz system without a
> successful junit or selenium test and peer approval.
> >
> > then you will have a production ready 'master' branch most of the time
> and the demo server can act as a staging server.
> >
> > Regards, Hans
> >
> >
> >
> >
> > On 21/08/14 12:41, Jacopo Cappellato wrote:
> >> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
> >>
> >>> This is one reason which would refrain me to jump right now. With of
> course all the burden and especially the inherent risks of permutation.
> >>>
> >>> I think that Pierre's idea of a branch is a reasonable compromise
> >>>
> >>> Jacques
> >> Of course, if we will ever try the switch to Gradle, this would be done
> in the trunk only, not backported to releases; so the instability period
> will only affect the trunk.
> >> This is exactly the purpose of trunk vs release branches.
> >> The fact that there are persons that use the trunk in production, and
> that don't want it too change much because this may cause them to work to
> keep their custom tools/code up-to-date, is a burden that slows down the
> evolution of OFBiz.
> >>
> >> Jacopo
> >
>
>

Re: Discussion: continuous deployment was: Discussion: migrating from Ant to Gradle

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

What you describe is (I guess) essentially this:

https://www.atlassian.com/git/workflows#!workflow-gitflow

and I know it (we have projects following this pattern) and it works pretty well; this is *not* the workflow that OFBiz community is currently implementing. Theres is no right or wrong workflow... it depends on the project and requirements.
The fact that your company is following a different workflow that works for you is great but it doesn't mean that the OFBiz community has to act accordingly.
I am wide open to discuss the migration to different workflows and tools (like Git) but for now let's stick to what we have and not on what you have decided for your company.

Jacopo


On Aug 21, 2014, at 8:13 AM, Hans Bakker <ma...@antwebsystems.com> wrote:

> Jacopo,
> 
> Sorry to react on your comment at the end of your post below.
> 
> May i ask you to study continuous deployment? Up to now the trunk was always very stable. Once in a while some problems, but they never lasted more than a couple of days.
> 
> At AntWebsystems we are supporting continuous deployment (expect a linkedin post on this) and we upgrade our production OFBiz version every month by hand picking a trunk version which we think works. Then this version will run on our demo server for one month and when no problems will be put in production. This is working fine for the last 3 years.
> 
> So what we are doing is upgrading the ofbiz core system every month, which a step in the direction of continuous deployment. However, the goal is that before any commit is going into trunk it should be tested (selenium and junit) and approved by at least another committer (peer review)
> 
> I would like to know how others think about continuous testing and continuous deployment. If you make the master (sorry trunk) branch deliberately unstable and not create development branches, you kill the continous deployment principle.
> 
> You want innovation?
> 1. Convert to GIT
> 2. install Gerrit for peer review
> 3. Install Jenkins for running all tests daily, also run tests for the development branches
> 4. Do not allow any change in the master branch ofbiz system without a successful junit or selenium test and peer approval.
> 
> then you will have a production ready 'master' branch most of the time and the demo server can act as a staging server.
> 
> Regards, Hans
> 
> 
> 
> 
> On 21/08/14 12:41, Jacopo Cappellato wrote:
>> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>> 
>>> This is one reason which would refrain me to jump right now. With of course all the burden and especially the inherent risks of permutation.
>>> 
>>> I think that Pierre's idea of a branch is a reasonable compromise
>>> 
>>> Jacques
>> Of course, if we will ever try the switch to Gradle, this would be done in the trunk only, not backported to releases; so the instability period will only affect the trunk.
>> This is exactly the purpose of trunk vs release branches.
>> The fact that there are persons that use the trunk in production, and that don't want it too change much because this may cause them to work to keep their custom tools/code up-to-date, is a burden that slows down the evolution of OFBiz.
>> 
>> Jacopo
> 

Re: Discussion: continuous deployment was: Discussion: migrating from Ant to Gradle

[Adrian Crum <ad...@sandglass-software.com>]

I have been a member of this community for 10 years, and I don't agree 
that "Up to now the trunk was always very stable." The trunk has always 
been the bleeding edge of OFBiz development and design - and that is the 
reason we have release branches.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/21/2014 7:13 AM, Hans Bakker wrote:
> Jacopo,
>
> Sorry to react on your comment at the end of your post below.
>
> May i ask you to study continuous deployment? Up to now the trunk was
> always very stable. Once in a while some problems, but they never lasted
> more than a couple of days.
>
> At AntWebsystems we are supporting continuous deployment (expect a
> linkedin post on this) and we upgrade our production OFBiz version every
> month by hand picking a trunk version which we think works. Then this
> version will run on our demo server for one month and when no problems
> will be put in production. This is working fine for the last 3 years.
>
> So what we are doing is upgrading the ofbiz core system every month,
> which a step in the direction of continuous deployment. However, the
> goal is that before any commit is going into trunk it should be tested
> (selenium and junit) and approved by at least another committer (peer
> review)
>
> I would like to know how others think about continuous testing and
> continuous deployment. If you make the master (sorry trunk) branch
> deliberately unstable and not create development branches, you kill the
> continous deployment principle.
>
> You want innovation?
> 1. Convert to GIT
> 2. install Gerrit for peer review
> 3. Install Jenkins for running all tests daily, also run tests for the
> development branches
> 4. Do not allow any change in the master branch ofbiz system without a
> successful junit or selenium test and peer approval.
>
> then you will have a production ready 'master' branch most of the time
> and the demo server can act as a staging server.
>
> Regards, Hans
>
>
>
>
> On 21/08/14 12:41, Jacopo Cappellato wrote:
>> On Aug 20, 2014, at 10:26 PM, Jacques Le Roux
>> <ja...@les7arts.com> wrote:
>>
>>> This is one reason which would refrain me to jump right now. With of
>>> course all the burden and especially the inherent risks of permutation.
>>>
>>> I think that Pierre's idea of a branch is a reasonable compromise
>>>
>>> Jacques
>> Of course, if we will ever try the switch to Gradle, this would be
>> done in the trunk only, not backported to releases; so the instability
>> period will only affect the trunk.
>> This is exactly the purpose of trunk vs release branches.
>> The fact that there are persons that use the trunk in production, and
>> that don't want it too change much because this may cause them to work
>> to keep their custom tools/code up-to-date, is a burden that slows
>> down the evolution of OFBiz.
>>
>> Jacopo
>