1. Release Management at Xilinx Dilip Deshpande January 24 th, 2006

2. 11i 7-Dec-15 About Xilinx Sector – Semiconductors Revenue – 2 Billion Dollars Number of employees worldwide – 3700 Major ERP Application – Oracle 11.5.9 Modules – HR, Finance, OM, CRM, Planning (APS)

3. 11i 7-Dec-15 Background A formal release management process was adopted in 2001-02 during the Oracle Applications upgrade from 10.7 to 11i. Before the upgrade project, we had projects being worked and moved into production with very little coordination between them. Developers mostly moved their code into production themselves and testing was carried out by business users with very little attention to regression or end to end integration testing. The net result was unacceptable production downtime.

4. 11i 7-Dec-15 Historical Context

5. 11i 7-Dec-15 Evolution of the Release Process The early release model Monthly Release for minor changes Quarterly Release for major projects Emergency changes for critical issues The Projects in a Quarterly Release were tested in the same integrated instance and moved into production in a carefully coordinated manner. The business users were involved in testing and also in post production verification.

6. 11i 7-Dec-15 Evolution of the Release Process Contd.. Sarbanes Oxley (SOX) Impact In the process of getting certified for SOX compliance, we further refined our release process and implemented our change control process using Mercury’s IT Governance Center application. The major impact of SOX on the release process were.. 1.Very stringent segregation of duties – Developer and Installer of code cannot be the same person, which resulted in a centralized group that installed change requests. 2.Approved Test Plan for each change 3.Proof of Testing or Test Evidence – This resulted in streamlining of testing and usage of Mercury’s Test Director as the testing tool.

7. 11i 7-Dec-15 The process was further refined as we added the Weekly Releases to accommodate very minor changes – certain changes to reports and alerts, data fixes etc. The Daily Release was also added to accommodate certain repetitive fixes that were predefined and approved by the release manager. The later release model Daily Release for pre-approved support fixes Weekly Release for minor changes Monthly Release for minor projects Quarterly Release for major projects Emergency changes for critical issues Evolution of the Release Process Contd..

8. 11i 7-Dec-15 Impact of Quarterly Major Releases Major releases were for bigger projects and went through 2 rounds of CRP testing and 1 round of UAT testing. Business users played a big part in the major releases Business users were involved in CRP and UAT testing for projects Regression testing was also carried out by business users during CRP and UAT testing We went back to our Business Stake Holders to review the release schedule as it had been in place for a while. The Business stake holders included HR, Finance and Operations. The Business stake holders gave us feed back about the Schedule and Testing effort.

9. 11i 7-Dec-15 Impact of Quarterly Major Releases Contd.. The Pain Points.. Schedule – Current Major Release schedule has negative Business impact on the following two areas: Planning- current release schedule falls in the week critical planning processes are run subjecting the business to additional effort and risk to plan Current release schedule for Aug causes resource issues during software release cycle and creates risk to meeting customer shipment metrics

10. 11i 7-Dec-15 Impact of Quarterly Major Releases Contd.. Testing: – Business resources are spending too much time testing – Need to develop expertise in how to write test scripts and in automation of tests

11. 11i 7-Dec-15 Solution Reduce release to 3 times per year (Q1, Q2, Q3) and in the 3 rd week of the month Use of automated tests scripts for regression testing This change resulted in Avoiding conflicts with the release schedule Ease the load on Business Users

12. 11i 7-Dec-15 Major Release Schedule Major Releases are always done during month 2 of the fiscal quarter – Q1, Q2- Major Releases 3 rd weekend of fiscal month – Q3- Major Release 4 th weekend of fiscal month – Q4- no Major Release on schedule If Major Release needed for business critical changes, Release would be 3 rd weekend of fiscal month CRP1 usually starts 10 weeks prior to Release