20160121 - Meeting minutes, Thursday January 21rst 2016 - OpenNCP Task Force - Release Management.
Release Management Process and Workflow.
Estimated: 15:00 to 16:00 CET.
Performed: 15:09 to : 16:00 CET.
Agenda:
- Infrastructure
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:
https://openncp.atlassian.net/wiki/x/XQAYAw
https://openncp.atlassian.net/wiki/x/OQCp- 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.
- 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"
- Unique way to format the code, what about using one file defining the formatting of code? NetBeans to Eclipse, vice versa?
Current Process:- Infrastructure:
- Current tools used: Bitbucket, JIRA, Jenkins, Artifact repository on join -up...
- Current administration of Bitbucket:
- Admin can create users etc. Rights are then defined per repository... There are 4 types of administration... so it is possible to delete access to ensure that only EC can make a release
- Who are the current administrators?Alexandre Santos, Licinio Kustra ManoRui Alves (Unlicensed), Massimiliano Masi etc.
- The pros and con's of the 2 possible approaches to commit code are discussed:
- The developers are committing code to the repository, with access to develop branch only. Then only admin DG SANTE has the authorization to the code on the master branch to make a new release.
- 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.
- We have more control on what is done. It does not exclude someone who wants to develop and then to make a pull request.
- This approach fits well to our team & way of working (developers are identified, they already know the project etc.). but we could add some formalization in term of formatting, e.g. Commit guidelines.
- 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.
- This approach is more appropriate in bigger teams, developments on Internet... Using pull request, someone from the Master team has to read all the source code & check if the source code complies to the formatting decided etc.
- Restrictions (e.g. absence of the main developer...)
- The developers are committing code to the repository, with access to develop branch only. Then only admin DG SANTE has the authorization to the code on the master branch to make a new release.
- .
- We don't know the time line yet since we don't know when environments will be available.
- 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
- Before export we will have to clean, same for Bitbucket.
Link to a blog on sonarcube provided by Kostas Karkaletsis after the meeting:
https://openncp.atlassian.net/wiki/display/ncp/2016/01/21/How+to+use+SonarCube+in+your+maven+projects+to+analyze+the+code+quality
No meeting planned