Amsterdam Release Lesson Learned Catherine Lefvre Eric Debeau

Amsterdam Release - Lesson Learned Catherine Lefèvre, Eric Debeau September 27 th, 2017

Lesson Learned Areas • • • Communication – Wiki, Mailing Lists, IRC JIRA Management Development Infrastructure Release Management PTL Role Architecture Code Review Labs and Test Environments Open Source Values “The project is big, we need to make sure we are helping the project teams and not driving them crazy” 2

Communication – Wiki, Mailing Lists, IRC • Too many projects, too many meetings, proliferation of wiki pages makes it hard to stay on top of what impacts you or know what you should be paying attention to. • A lot of information on the wiki - it is very hard to locate information - some information no longer accurate • Solution: Review the Wiki structure and content; identify a fast communication channel - Re-organize pages Define a common structure Perform some clean-up (delete redundant pages or unused pages, consolidate content) Consolidate the questions and answers under 1 section of Confluence/JIRA Use Hip. Chat - https: //www. atlassian. com/software/hipchat 3

JIRA Management • More control over creating JIRA “Tasks” created for a project The PTL gets surprised by changes being made to their project that impact the project plan. Solution: Empower PTL to run their team - Only the PTL should be able to manage activities in the Project/Sprint - Define the JIRA workflow based on PTL’s needs 4

Development Infrastructure • Reduce the overhead on the projects generated by the Infrastructure and consult impacted projects regarding any Infrastructure change • Solution: Scale the development environment/resources based on current needs - Increase the support on CI-Management project i. e. Jenkins, Sonar, JIRA etc. adding Asia/EMEA timezone - Increase the LF infrastructure in order to have a more reliable and better performing LF server-side components that developers rely on - Review the schedule of Jenkins jobs so these are not running at the same time - Clean-up unuseful Jenkins Jobs and provide a definition of the existing Jenkins usage - Consult impacted PTLs before changes being implemented and communicate broadly these modifications - Provide more frequently an update regarding potential License conflict - Consider Infrastructure & Processes for non-Java code (i. e. Python) - Adding a new repository to Gerrit requires a fairly involved process (PTL must add repo to list on Wiki, then notify release manager, who then must solicit TSC approval, and only then may repo be requested from LF). Let’s simplify the process by having the PTL update the wiki with the new repo and then contact the LF directly without need for Release Manager and TSC approval. - Provide training material regarding LF infrastructure/onboarding 5

Release Management • Release Management process is not necessarily aligned with Software Development Practices - Requirements imposed on projects and late add-on criteria - CSIT and documentation requirements required much larger effort on an already limited set of resources - Lack of early requirements and understanding pushed work later in the cycle. • Solution: Re-adjust the Release Management process in order to support PTLs more effectively during the release to successful execution - Review the Milestone check list items and the milestone dates with PTLs - Ensure that PTLs’ feedback are considered in order to re-adjust the Release Management Process - No additional project, scope, milestone criteria post-M 1 (Planning) to avoid any milestone jeopardy - Consider Processes for non-Java code (i. e. Python) 6

PTL Role • Expectation of PTL are huge - They are expected to be scrum masters, technical leads, committers, representatives on all meetings that have cross-component impacts, participate in architecture discussion, attend TSC calls, and the list goes on. . . • Solution - R 2 projects should consider having a PTL that is providing the technical leadership - A project manager helping with leading the project and being the representative on the many calls that don’t really deal in technical issues. . 7

Architecture • PTLs are responsible for the Architecture of their components while no clear E 2 E architecture guidelines are provided, making it difficult to build the platform as a generic framework since there is the risk of discovering unexpected crossdependency late in the development process. • Solution: Architecture Committee should not only advice but also review if the architecture suggested by the project teams is harmonized across all the components, identifying cross-dependencies. - Architecture Review should be performed prior the Functionality Freeze in order to ensure the consistency across the components - Identify the cross-dependency (i. e. DMaa. P, AAF, ESR and MSB need to be done before others) and ensure that the E 2 E timeline is considering them adequately to reduce development delays - Understand (or accept) the fact that ONAP is not an out of the box production platform. If this is better understood, then realistic expectations would be aligned. - Agree on less meetings, more hands on work. This goes hand in hand with the fact that there were not enough full-time technical resources to help with the work, in which time expectations were not aligned to the number of resources available 8

Code Review • Significant number of people being not part of the Amsterdam project are submitting additional source code. - This in itself is not a bad thing - In many cases, reviewing and investigating these proposed changes has been very time consuming and with the mandate that no submit be greater than 36 hours puts more pressure on already stressed resources and really doesn’t allow the team to prioritize their efforts efficiently as they approach a major deadline. • Solution: Increase the speed of the code review. - Committers should not be the bottleneck to review the submitted source code. - Delegate the review to the contributors while committers remain focused on the merge activities - Ensure that the release branch is created at M 4 and extend the 36 hours review period to 72 hours on the non-Amsterdam source code. 9

Lab & Test Environments • Better understanding about lab and test environments. How applications are pulled into these environments. • Solution: Provide a wiki page containing Lab Strategy and Network Topology - How to require Access grants What is installed on these labs (containers + version per VMs) How/When these labs are upgraded The lab plans should be clear at the M 1 or M 2 milestones. Consider additional testing framework that are needed to increase test coverage (i. e. Arquillian) 10

Open Source Values • Better understanding about the Open Source Values and Principles. • Understand the Agile Values and Practices • Do not feel exposed. Share ideas openly • Solution: Be transparent, share your concerns – you are not alone Invest in Agile training and coach - Do not wait the PTL Weekly meeting to speak up - Setup a meeting with your peers (Call them directly) 11

s Thank You