Time to parallelize development & maintenance ?

[Olivier Sarrat]

Hi everyone,

In order to speed up the response time to bug report, it might be the right time to start parallelizing new features developement and corrective maintenance.

We could use the following basic branching & versioning & testing model:

• versioning w.x.y.z, which will evolve according to:
  
• w: major release, for any critical new very large feature, big change in architecture, etc.
• x: any new feature which changes the data model
• y: any new feature that doesn't change the data model
• z: any bug fix
• branching
• "master" will remain the up-to-date development trunk always ready to be installed for all new developers (must build)
• one branch for each "w.x.y" where we would have tags to mark each new bug fix version (z)
• testing
• rigorous testing (application of the test plan) for any new "w.x" version (change of model)
• potential rigorous testing depending on complexity of new features introduced in a "y" version
  
• no rigorous complete testing for each new "z" release
  

What do you think about this ?

In addition, do you have ideas and solutions for fast automatic or semi-automatic upgrade of Java web applications that we could use to upgrade quickly when a "z" version is released ?
I found this article on this issue : http://www.javaworld.com/article/2074720/build-ci-sdlc/update-distributed-applications.html
Of course, very cheap solutions to implement are favored...

Best,

Olivier.

--

Olivier Sarrat
Ingénieur Systèmes d'Information / Information System Engineer

>>Sigmah (Twitter, Facebook, Linkedin, Google+)
Animateur du projet / project facilitator

>>Groupe URD (Twitter, Facebook)
La Fontaine des Marins
26170 Plaisians
Tel: + 33(0)4 75 28 29 35

Mobile: +33 (0)6.34.31.42.07    -    Skype: osarrat.urd

Par respect pour l'environnement,

n'imprimez ce mail qu'en cas d'absolue nécessité

 

[Brendan Le Ny]

Hi Olivier,

Le 06/12/2016 à 17:27, Olivier Sarrat a écrit :
> What do you think about this ?

I think it's a very sane approach to have a version cycle dedicated to
stabilize the software, accepting only bug fixes, rejecting all others
changes.

But I think your approach may be too hard to maintain. I mean, let's
suppose we have following existing versions (w.x.y.):
* 2.2.0
* 2.2.1
* 2.2.2
* 2.3.0
* 2.3.1
* 2.3.2
* 2.3.3

If someone fix a bug, will we have to upgrade the 7 branches? Knowing
that every version may have moved things and make a same patch not
usable... Quite hard and time-consuming.

As you said, it's about opposing "new features development" and
"corrective maintenance" so I'd said, two branch should be sufficient.
One for integration of evolutions (master branch) and one with the last
officially supported/stable version, I guess. It may be easier to attain
your goal of "faster bugfix to production". This should also be easier
to understand for contributors because the instruction could be to
"always push bugfixes to 'maintenance' branch, always push evolutions to
'master' branch", instead of having to find what is the branch(-es!) on
the PR should be done. Naming the branch by the maintained version
should also works but we have to be clear to where the developer fixing
the bug have too push.

Hope that helps...

--
Brendan Le Ny, Code Lutin
bl...@codelutin.com
(+33) 02 40 50 29 28

[Olivier Sarrat]

Hi Brendan,

Thanks for this feedback !
This seem actually a much better approach.

And if I understand it correctly, we will need to delete and recreate
the "maintenance" branch each time a new version if released.
And in your proposition, we can keep my proposition for tagging releases
but we will just not make branches out of them.
Is that right ?

Best,

Olivier.

[Brendan Le Ny]

Le 15/12/2016 à 17:06, Olivier Sarrat a écrit :
> And if I understand it correctly, we will need to delete and recreate
> the "maintenance" branch each time a new version if released.

No. If 3.3 version is released, a "3.3" tag is published and tag "3.3"
is merged in "maintenance" branch (so people updating their
"maintenance" branch get the new code to maintain).

> And in your proposition, we can keep my proposition for tagging releases
> but we will just not make branches out of them.

Yes.

The workflow for the "maintenance" is
* accept bugfixes as pull-requests on "maintenance" branch
* when all bugs are fixed (according to roadmap), tag the maintenance
branch (incrementing .z)
* merge tag in "master" branch : because we need also to fix the coming
version (if we don't do that, the fixes will never be pushed in master
branch). This merge may not be easy since developments on master may
have the moved the code that the patch impacted. The good news is the
"maintenance" branch is tagged and ready to deploy, the merge, even if
hard, will not delay that.

We could start the new flow, which is a bit more complex that the
current one for the next version, as soon as 2.2 is released and have
some time to experiment it before adopting this workflow and make it
official (we me have to adjust details...).

Also, people must keep in mind that bugfixes should sometimes go to
"master" (RC cycle...): I know workflows are sometimes hard to push on
developers (used to SVN... pushing everything on master) so let's go
smoothly!

[Brendan Le Ny]

Hi Olivier,

Le 15/12/2016 à 17:33, Brendan Le Ny a écrit :
> We could start the new flow, which is a bit more complex that the
> current one for the next version, as soon as 2.2 is released and have
> some time to experiment it before adopting this workflow and make it
> official (we me have to adjust details...).

Now that 2.2 is tagged, we could try to experiment that new workflow we
talked about.

I can create the "maintenance" branch, starting from "2.2" tag, setting
version to "2.2.0.1-SNAPSHOT" (adding a "z" for bugfix like you
suggested in the current thread). "atolcd-bug-fixes" should go there IMO.

We well keep master for everything 2.3.

Or, if 100% developments are made by Atol, maybe we could keep things
simple and straightforward like today. It's up to you, depending on how
you feel about the urge "to speed up the response time to bug report"
you wrote about.

Also, for your information, we took 1 year for the 2.2 release candidate
cycle. That may help you decide making a decision:

git tag --format='%(creatordate:short)%09%(refname:strip=2)'
2016-09-13 2.2-beta4
2016-09-19 2.2-rc1
2016-11-24 2.2-rc2
2017-02-10 2.2-rc3
2017-03-13 2.2-rc4
2017-04-26 2.2-rc5
2017-09-13 2.2-rc6
2017-09-11 2.2

Don't hesitate if you have any question.

Regards.