20160114 - Meeting minutes, Thursday January 14th 2016 - OpenNCP Release Management Brainstorming

Release Management Brainstorming

 

Estimated: 11:00 to 12:00 CET.

Performed: 11:05 to 12:00 CET.

Agenda

  1. Release management handover
  2. Tools and software  
  3. Release 2.4.0
  4. AOB
  5. Next meetings 

LOCATION   

  • AdobeConnect:

http://ec-wacs.adobeconnect.com/openncp/
Room Passcode:  markus.kalliola or michele.foucart
------------------------------------------------------------------------------------------------
If you have never attended an Adobe Connect meeting before:
Test your connection: http://ec-wacs.adobeconnect.com/common/help/en/support/meeting_test.htm
Get a quick overview: http://www.adobe.com/products/adobeconnect.html
Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
------------------------------------------------------------------------------------------------

Participants:

Meeting Notes:

  1. Release management handover: 
    1. History:
      Throughout the Epsos project, there were different release managers succeed (Steen Manniche, Kostas Karkaletsis and Alexandre Santos). And they tried to keep the job roles aligned and working in the same way.
      The role of the release manager is really important because he is the guardian of the integrity of the source code, release etc.
       
    2. Components:
      OpenNCP is now a quite complex project with several technical components (more than 20 components), the architecture design separate components according their roles inside the NCP.
      For the time being, an OpenNCP version is a result of group of these components synchronized and updated as shown by the following link (OpenNCP release 2.4.0-RC1): https://openncp.atlassian.net/wiki/x/EQA-B
      Example: If the NCP of Portugal has an issue --> this issue will be fixed into the responsible component then a release of the artefact will be made with minor number and finally a new release of the OpenNCP itself with a minor number also X.X.1.
      For each release, a new page with explanations about what has been fixed, general information of the release etc.
      is created (https://openncp.atlassian.net/wiki/x/C4BIAQ)

    3. Improvements:
      Kostas Karkaletsis proposed to create a master pom file for the OpenNCP release who will manage the version of all components of the concerned release because of the number of components and complexity of the current OpenNCP.
      Example: OpenNCP-1.0.0 is composend by client-connector-1.0.1 and epsos-ws-server-3.5.0 etc.
      It will prevent manual download of the artefacts.
      Alexandre Santos: If you build an OpenNCP with master you have to build all components?
      TODO: Test faisability of the master parent pom.
      TODO: Check credentials into JoinUp server, who could release an artefact.


  2. Tools and software:
    1. Current situation:
      Source control tool is Git and hosted into a Bitbucket server (https://bitbucket.org/openncp/) and community release process id described in details Release Management and Release Plan and Actions.

       
    2. Source control management:
      Kostas Karkaletsis recommended to use Gitflow in order to simplify the use of Git, and it respects a standard successfully used by several development teams also in the open source domain.
      http://danielkummer.github.io/git-flow-cheatsheet/
      The repository should contain at least 2 branches:
      MASTER -->always current production version (for instance: version 1.0.0).
      DEVELOP --> source code of next version, this branch has to be always healthy while committing (Jenkins tests and build help to validate the commit). Version+SNAPSHOT (for instance: 1.1.0-SNAPSHOT).
      The gitflow model further operates with feature, release and hotfix branches.
      Example: New feature name SMP (Gitlfow command in order to create a new branch and start to work here --> then changing Git repository).
      Gitflow finish SMP --> merge automatic + delete new feature branch.
      Hotfix from master branch + correct + Gitflow finish --> merge master.
      Release --> freeze source code into DEVELOP branch and changing Pom file.

      All of the samples are executed according the following picture who describes the current way to work with branches:


    3. Organization of development tasks:

      Alexandre Santos highlighted some problems with TSL tasks several branches created and it causes problem to merge etc.
      In order to prevent this situation, two solutions are proposed by Kostas Karkaletsis and Alexandre Santos

      •   Forking the project, https://www.atlassian.com/git/tutorials/making-a-pull-request/ Good if not directly involved into the project.
         Applying permissions on projects, so only authorized and authenticated persons can push to master. All the other can only execute a pull request from the develop branch.

      Kostas Karkaletsis, Alexandre Santos, Joao Cunha and S prefer the second approach and it will be discussed into the dedicated Task Force.

      The second approach should be applied also in the following way: Pushes in develop branch should not permitted. Each one who wants to develop a new feature or solve a bug will have to create a branch for this and push this upon finish to Bitbucket and then create pull request to develop branch.

    4. Code quality:

      New approach, very small team of developers responsible for every commit on the repository, so indeed there is a need for quality review.
      DG SANTE is responsible for the quality Assurance --> Proposition: only authorized to push to MASTER branch.
      Set-up of a release management task force led by Natasha Carl, Alexandre Santos also wants to participate, he was responsible for the release management during Expand project.
      Marcello Melgara also wants to be in the loop.
      For information: every person interested to the project should fork and then create a new branch and then pull request to the origin.
      Pull request is a kind of warranty of freezing code, and keep integrity of branches, preventing merge as a nightmare.
      If there are doubts about PR (new feature, important changes etc.) it should be discussed validated and approved by the Technical Committee before merging.


  3. Release 2.4.0:
    Alexandre Santos What is the situation of the release 2.4.0 (Expandathon and final Expand release). Shall we make the release (already RC0 and RC1 portal + tsl bug fix)? Waiting feedback from Member States.
    TODO: Ask during the bi-weekly meeting and technical committee.

  4. AOB:
    None.

  5. Next meetings:  
    To be planned during the next bi-weekly meeting.
     

NEXT Steps:

  • Organize next week meeting the TF release management.
  • Ask biweekly meeting situation of the release 2.4.0.
  • TODO: S Summarize propositions for the release management Task force into a document (support and background document).