Release Management Process and Workflow.

21 Jan 2016 

Estimated: 15:00 to 16:00 CET.

Performed: 15:09 to : 16:00 CET.

Agenda:

1. Infrastructure
   
2. Release Management Workflow 
   
3. Release 2.4.0
4. AOB
5. Next meetings 
   

Location:

• AdobeConnect:

http://ec-wacs.adobeconnect.com/openncp/
Room Passcode:  Ask if necessary michele.foucart or markus.kalio
------------------------------------------------------------------------------------------------
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:

Joao Cunha

Kostas Karkaletsis

...

YacoubouY

S

Alexandre Santos

Meeting Notes:

1. Infrastructure: Current Infrastructure:
2. Since the current process is fine, this task force will not revolutionize the current way of working
Current tools used: Release Management Workflow:Current Process:
https://openncp.atlassian.net/wiki/x/XQAYAw
https://openncp.atlassian.net/wiki/x/OQCp

Image Added
1. The task force has analysed the current process. The process is well defined and efficient. There is no major points to improve so this task force decides not to revolutionize the current way of working.
2. What needs to be changed is the administration of the tools which should be moved now to the EC which is responsible for the quality of the code, harmonization of format and of the releases in general => See next point on "Infrastructure"
3. Unique way to format the code, what about using one file defining the formatting of code? NetBeans to Eclipse, vice versa?


3. Infrastructure: 
   1. Current Infrastructure:
      1. Current tools used: Bitbucket, JIRA, Jenkins, Artifact repository on join -up...
      2. EC will need admin credentials for all tools and in particular administration rights of Bitbucket as responsible of the releases
      3. Who are the current admin in Bitbucket?Alexandre Santos, Licinio Kustra ManoRui Alves (Unlicensed), Massimiliano Masi etc. Current administration of Bitbucket:
         
         1. Admin can create users etc. Rights are then defined per repository...
          
         2. There are 4 types of administration... so it is possible to delete access
         We should have a list of developers
         3. to ensure that only EC can make a release
         4. Who are the current administrators?Alexandre Santos, Licinio Kustra ManoRui Alves (Unlicensed), Massimiliano Masi etc.
         5. The pros and con's of the 2 possible approaches to commit code are discussed:
            
            1. The developers are committing code to the repository. Commit code => , with access to develop branch only, while admin DG SANTE have access to the main branch to be the only one being able to make a new release
            2. Other possible scenario: development of a new feature or bug.
            3. Either pull request to develop, all the developpers have rights to push dev & then only . Then only admin DG SANTE has the auto authorization to put the code on the master branch and to make the release. Or developers only have possibility to develop on the branch and then make a pull request? Kostas Karkaletsis First approach looks clearerfirst approach more a new release.
               1. More appropriate for a small team working on the same project, within same company. Simpler, faster. But everybody from the team having access to the development branch has to know the formatting etc.
               2. We have more control on what is done. Does It does not exclude someone who wants to develop and then to make a pull request?.First
            4. 1. This approach fits well to our team & way of working
            etc
            5. 1. (developers are identified, they already know the project etc.). but we could add some formalization in term of formatting
            etc. =>
            6. 1. , e.g. Commit guidelines
            ?Second one (e.g Github)
            7. 1. .
            8. Other possible scenario: development of a new feature or bug. Developers only have possibility to develop on the branch and then make a pull request.
               1. This approach is more appropriate in bigger teamteams, developments on Internet... Using pull request: , someone from Matsre the Master team has to read all the source code & check if the source code complies , to the formatting decided etc.
               2. Restrictions (e.g. absence of the main developer..Common agreement: we keep the first option and if .)
               There is a common agreement on the first approach and if there are issues and/orf or lot of new developers join then we canstill can still move to the second option. Escecially also for restrictions of second could imply (e.g absence of the main developper etc.)
               
            What are the mandatory artefacts? into Join-up that will need to be migrated. Restriction from the group id.
            1. .
            . Kostas Karkaletsis will have a look at the Jenkins library and come back
            1. 
               
               
   2. eHealth CEF Infrastructure:
      Migrate ressource
      1. Migration of the resources from Atlassian to the one provided by EC (CEF), which is using the same tools, also publicly open and hosted within the Commission
      1. Before export we will have to clean, same for Bitbucket. It will work in the same way.
      2. CEF infra
         1. . CEF infrastructure is for purpose of open source projects, it will work the same way.
         2. We don't know
         timeline Sonar? Giving
         1. the time line yet since we don't know when environments will be available.
         2. Migration:
            1. What are the mandatory artefacts into Join-up that will need to be migrated? Restriction from the group id... Kostas Karkaletsis will have a look at the Jenkins library and come back
            2. Before export we will have to clean, same for Bitbucket.
            3. Tools: Jenkins is not supported by the EC. So for Jenkins we cannot ask for support etc. So we'll try to migrate from Jenkins to Bamboo
            and YacoubouY will be responsible for the migration.
          
         1. 1. 1. Proposition from Kostas to use Sonarcube. This tool is giving good metrics regarding the quality of the source code.
         It is used

         1. 1. 1. 1. Link to a blog on sonarcube provided by Kostas Karkaletsis

         and is a very useful tool. S will see if this tool is supported by the Commission.
      Release Management Workflow:
      1. Current Process:
         

         1. 1. 1. 1. after the meeting:
                     https://openncp.atlassian.net/wiki/

         x/XQAYAw
         https://openncp.atlassian.net/wiki/x/OQCp
         Image Removed
      2. The current process is well defined and efficient, so no need to change.
      3. Unique way to format the code, what about using one file defining the formatting of code? NetBeans to Eclipse, vice versa?
          

         1. 1. 1. 1. display/ncp/2016/01/21/How+to+use+SonarCube+in+your+maven+projects+to+analyze+the+code+quality

                  2. S will see if this tool is supported by the Commission.
            2. Yacoubou Waolany will be responsible for the migration.
               
               
   3. Release 2.4.0 
      1. Joao Cunha and Heiko Zimmermann will test, then we can make the release.
      1. Jerôme will be responsible for the release, with the help of Alexandre Santos
      2. Release date: Parent Project:
         1. Add a parent project controlling the dependencies of the release, will include client connector etc.
         2. Especially because there are more than 20 differents different components in Bitbucket so it has the advantage to manage the dependences at one place.
         
         
   4. AOB:
   5. Next meetings:    
      No meeting planned
       

   Next Steps:
   

    This task force reached an agreement on release management for the future releases. Ad hoc discussions can therefore be included in the bi-weekly meeting or in the Technical Committee.