Customer benefits Change of business models Customer acceptance Support agreement ….
The WMR Agile transformation has established the foundation for regular, flexible and high product quality releases
Customer request Reduce Time To Market and minimum cost of unreleased features (Ullared) Flat work load over the year instead of getting intense release work during vacation periods Offer the customers the best available SW Reduce the cost for CI-HW. The cost increases with the number of supported tracks. The agile test methodology increases test efforts significantly and that effort needs to be concentrated to few tracks. We can not afford to invest to test all current tracks with at full test coverage Reduce the development and maintenance cost. Reduce cost of poor quality. (likely a fault that is found in an earlier release is corrected in a later) Reduced friction and disturbances in PD since features are released as they are ready instead of sub optimizing to meet the half-year release
Establish a common goal for WMR independently of program, site or product
People motivation Continuous depl offers closer cooperation with customer (no release project needed) Continuous flow in PD Superior quality and reliable CI
To take advantage of the fast-paced responsiveness of a continuous delivery environment, the entire organization–both delivery teams and management– needs to be mature—from embracing the process changes required to respond rapidly, to engaging in the collaboration required between development and operations, to embracing an adaptive, exploratory mindset.
We have established a Continuous Integration system that constantly keeps the RAN product on a close-to-RFS level.
To improve quality even further, we want to take CI to the next level and once per sprint get feedback from a live customer network.
T-Mobile USA has expressed interest in being that customer.
The intention is to start mid November, right after we have built the W14A GA candidate, and then go live with SW from the main track every third week. This effectively means having RFS every third week going forward.
Reach RFS quality every third week Be backwards compatible on all external interfaces and have a backwards compatible system behavior since we will deploy our SW in a live customer network without changing anything else in the network Fulfil regulatory requirements on functionality (emergency call priority and positioning, cell broadcast services, …) and characteristics (radio performance, …) every third week Don’t include a new sensitive technology with Trade Compliance restrictions in the main track before having received ok from Swedish national authorities (example: we are not allowed to export sensitive American cryptography technology to most countries) Don’t include a new commercial third party product (or a new version of an already used one) in the main track before contracts and payment routines are in place Don’t include a new free open source product (or a new version of an already used one) in the main track before the license conditions have been reviewed and accepted by legal experts Find ways to handle risky product changes. We traditionally do them when we have a long time until the next FOA, but with customer deliveries every third week the next customer delivery is never more than three weeks away… Plan development so that incomplete features don’t cause problems in the live network
Since the RBS and RNC contain SW from PDU WMR, PDU PLF, PDU LMR ,PDU HW and PDU EI, all five PDUs need to address the bullets above.
Continuous Deployment | Stefan Nilsson | LTG-23