Release Management Process and Workflow.
Estimated: 15:00 to 16:00 CET.
Performed: 15:09 to : 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:
- Infrastructure:
- Since the current process is fine, this task force will not revolutionize the current way of working
- Current tools used: JIRA, Jenkins, Artifact repository on join -up...
- EC will need admin credentials for all tools and in particular administration rights of Bitbucket as responsible of the releases
- Who are the current admin in Bitbucket?
- Alexandre Santos, Licinio Kustra ManoRui Alves (Unlicensed), Massimiliano Masi etc. Admin can create users etc. Rights are then defined per repository...
- There are 4 types of administration... so it is possible to delete access
- We should have a list of developers committing code to the repository. Commit code => 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
- Other possible scenario: development of a new feature or bug.
- Either pull request to develop, all the developpers have rights to push dev & then only DG SANTE has the auto to put on master branch and make the release. Or developers only have possibility to develop on the branch and then make a pull request? Kostas Karkaletsis First approach looks clearer
- first approach 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. We have more control on what is done. Does not exclude someone who wants to develop and then to make a pull request?
- First approach fits well to our team & way of working etc (developers are identified, know the project etc.). but we could add some formalization in term of formatting etc. => Commit guidelines?
- Second one (e.g Github) is more appropriate in bigger team, developments on Internet. Using pull request: someone from Matsre team has to read all the source code & if the source code complies, formatting decided etc.
- Common agreement: we keep the first option and if issues and/orf lot of new developers join then we canstill move to the second option. Escecially also for restrictions of second could imply (e.g absence of the main developper etc.)
- first approach 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. We have more control on what is done. Does not exclude someone who wants to develop and then to make a pull request?
- 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. It will work in the same way.
- CEF infra is for purpose of open source projects
- We don't know timeline yet since we don't know when environments will be available
- Current Process:
https://openncp.atlassian.net/wiki/x/XQAYAw
https://openncp.atlassian.net/wiki/x/OQCp - The current process is well defined and efficient, so no need to change.
- Unique way to format the code, what about using one file defining the formatting of code? NetBeans to Eclipse, vice versa?
- Current Process: