Release Management at Xilinx

1
Release Management at Xilinx
Dilip Deshpande January 24th, 2006
2
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
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
Historical Context
5
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
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 Mercurys IT Governance Center
  application. The major impact of SOX on the
  release process were..
• 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.
• Approved Test Plan for each change
• Proof of Testing or Test Evidence This resulted
  in streamlining of testing and usage of Mercurys
  Test Director as the testing tool.

7
Evolution of the Release Process Contd..
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
8
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
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
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
Solution

• Reduce release to 3 times per year (Q1, Q2, Q3)
  and in the 3rd 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
Major Release Schedule

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