[sakai2-tcc] Improving the release process

Tue Apr 2 09:57:40 PDT 2013

In practical terms, with no change to the degree or kind of testing, it would be equivalent or better to have more numbered releases along the maintenance branch.

Currently, because releases are infrequent and there are good fixes in the branches, many just pick a revision (to run or use as a patch base), abstract of any release planning or testing. More releases would mean that fewer groups would fall in the gaps, distributed randomly across the revisions. I don't think that this changes the testing profile or exposes a new demand, but basing on a known point does make the forensics easier if someone is experiencing an issue.

I think the release frequency and the level of regression testing are largely independent, though more releases means testing is more tractable. If we have untested or incomplete stuff in the branches, people are already running it, whether there is a release or not. To my mind, more frequent releases actually give us a bit more cushion and more reasonably scoped inspection opportunities in case of an unseen regression, and more people will sync to our "all clear" signal.

I would generally suggest that "continuously releasable" is a red herring given our standing diligence, release, and adoption patterns. Our release discussions now hinge on sensible functional change grouping and available effort to execute releases -- not how hardened the branch is. I think QA is neutral or positively affected by a better defined and more frequent release pattern.

Thanks,
-Noah

On Apr 2, 2013, at 12:34 PM, John Bush wrote:

> I agree with Beth and Steve, the indie idea never worked for us, and
> we've just worked around it for years.  Re task 2, we are already
> releasing every two weeks or so, so I'm neutral on that.  In addition
> to needing task 3 for task 2, I worry about quality assurance.  The
> only way to really be confident and do it in a resource sane way is to
> have more automated testing.   This is deeper than a server just
> starting up.
> 
> On Tue, Apr 2, 2013 at 6:20 AM, Beth Kirschner <bkirschn at umich.edu> wrote:
>> I agree that the experiment with indies has failed their intended goal and doesn't reflect how Sakai is currently maintained. I worry about the effort to once again re-invent the process, but in general I'm supportive. If we have frequent Sakai releases, this could negate the need for those modules that truly do meet the ideals of an indie (e.g. Lesson Builder, Basic LTI, etc.).
>> 
>> - Beth
>> 
>> On Apr 2, 2013, at 7:13 AM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
>> 
>>> Hi all
>>> 
>>> I'd like to have a discussion around improving the release process with respect to having more releases per year and making the release process itself faster.
>>> 
>>> In most cases, the indies have failed in their intended goal. That is, allow off cycle releases. This would have been a perfect process if all modules were individually maintained and actively developed as project teams could release as they desire. Some projects did this well but for most there was no use. They were versioned along with the main CLE code but required an extra couple of steps to release.
>>> 
>>> Coupled with a lot of deployers wanting to have the source for patching or some other reason, it just meant more overhead for doing a local build, and the creation of the -all releases and a lot of confusion about where the source code was, how to pull it in and modify it.
>>> 
>>> People expect all of the source to be there in a checkout of an open source project, it wasn't and it was kind of odd - "but the modules are binaries in the repository, unzipped at deploy time, etc etc".
>>> 
>>> What follow are numbered tasks that I believe need to occur. They come from solid experience in implementing this process for over twenty applications coming together into one final product. They are not yet formal proposals until we discuss. I've just numbered them for clarity.
>>> 
>>> Task 1: Scrap all indies, re-version (if appropriate) back in line with the CLE versions, and clean up the externals and poms etc.
>>> 
>>> Task 2: The speed of releases must increase. We cannot have a fix committed the day after a maintenance tag is released, for it to sit there for months until the next big release happens. We should be able to make a minor release quickly. This absolutely must occur if 1 goes ahead.
>>> 
>>> Task 3: To facilitate 2, we must have the branch in a constantly releasable state. That will mean no dependency on snapshot artifacts within tools. This needs a bit more thought but is out there for discussion. I believe with a bit of top level pom work we can make this happen. One thing to keep in mind is offline builds.
>>> 
>>> Task 4: The deploy to Maven Central needs to be expanded. It is currently only being done for indies [1] but needs to be done for all artifacts, as per 2.8 and earlier releases (though they go to the Sakai maven repo). This allows contrib projects to build properly being able to find the correct versions of the artifacts they need.
>>> 
>>> Task 5: Remove dependency on Jenkins as a release platform. Unless Jenkins can be setup as a simple server that runs a build and kicks the artifact out, then it is too complex and you might as well use the command line. Logging in to the server, editing scripts [2] or anything else that needs to be done is silly. And if something goes wrong, we need to troubleshoot the jenkins server. A set of clear instructions should be all that is required.
>>> 
>>> Task 6: Rationalisation of the base and master poms should occur where necessary. This will also provide clarity for contrib projects which depend on a mix of base and master poms.
>>> 
>>> I propose all of the above with a view for implementation in 2.10.
>>> 
>>> In discussing, I beg that people refrain from turning this into a resourcing/volunteering issue and discuss the technical issues at hand. Who does what can come afterwards.
>>> 
>>> Finally, I make the above comments, suggestions and potential solutions purely because I want to see this process be improved, as a developer, deployer and someone that does the releases. And that is all.
>>> 
>>> regards,
>>> Steve
>>> 
>>> [1] http://central.maven.org/maven2/org/sakaiproject/
>>> [2] https://confluence.sakaiproject.org/display/REL/Sakai+CLE+release+guide
>>> _______________________________________________
>>> sakai2-tcc mailing list
>>> sakai2-tcc at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> 
> 
> 
> -- 
> John Bush
> 602-490-0470
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc