Configuration, Change & Release Management for internal and external Development, with Rational Team Concert

Transcription

1 Configuration, Change & Release Management for internal and external Development, with Rational Team Concert The 5th Italian Workshop on Eclipse Technologies (Eclipse-IT 2010) September 30th October 1st, 2010 Savona, Italy

2 Agenda Why do we need a Change Management process? Solution overview Project framework Results

3 IT Service Management Repeatable, controlled and measured process for software Configuration, Change and Release Management are necessary to insure that: the production environment works properly, the development process is controlled and the software is properly tested, the complexity and the risks related to changes are managed, as stated in IT Governance or IT Service Management frameworks like COBIT and ITIL. Customer/Business RFC / Projects Service Transi;on Service Opera;on User Services Change Mgmt IT Infrastructure

4 Agenda Why do we need a Change Management process? Solution overview Project framework Results

5 The solution is based on In order to define a Change Management solution based on RTC, it is necessary to define one or more process model which contains the design of the solution Different process models define different self contained develop/management process Every process model consists of the definition of all these different components: Work Item (Entity model) Configuration (Stream and component organization and hierarchy) Roles (Hierarchy and authorization) Workflow (States and actions organization) Behavior (operation advisor, operation participants, trigger, ) Planning (Iteration type and line of development) Process control (Query, report and dashboard)

6 Requirements In CCRM project design two different process model have been defined: CM (Change Management): it describes and manage the entire development and release process of applications internally developed. DM (Deploy Management): it describes and manage the release process of applications developed in outsourcing from third parts. From implementation point of view, the two process models have the following differences: CM process model performs the versioning of both source and binary elements, instead of DM process model which performs only binary element versioning CM process model compiles binary element in a controlled environment. In DM process model binary are provided by third parts. DM process model is designed to be used from less developers than the CM process model. For this reason it consists of less operations

7 Project Area e Team Area A process model cannot be used stand alone, but must be instanced in a Project Area A Project area is the minimum container defined in RTC. All the entities described in a process model are instanced in a Project area. Every single application must have a specific Project Area. Users are defined in a Project Area and then organized in one or more Team Area Users which belongs to a Team Area could have specific permission In CCRM project has been used a single Team Area for every Project Area In CCRM project the name of a Project Area has been defined using a 5 char code In the following slides this code will be identified with PRACD (Project Area Code) The process definition of a Project Area can be modified without changing the process model used to create the Project Area which remains as Process Template

8 Work Item definition In RTC work items represent the entity on which defined the change process Work items are grouped by type and category Every category could include different work item type. Every work item type could have different attributes and specific editors Every work item type which belongs at the same category share the same workflow In CCRM project, for both the process models, it has been defined the following work item category which consists of a single work item type: RUOrdinaria: it contains a work item type with the same name and represent a single release unit (RU), that is the minimum element that could be released for an application. This release will be performed following a standard process RUEmergenza: like the previous one, it contains a single work item type (with the same name of the category) and represents a single RU with a release which follow an emergency process (faster and with less controls of the standard) Activity: it contains the work item type TechnicalActivity and represents all the manual activity which have to be performed (if necessary) before to start the release

9 Work Item design RTC provides different standard work item attributes: Title, Description, Comments, Owner, Category, Team Area, Tags, Elapsed time, Forecast Date, Closure date. In CCRM project has been added some customized attributes: RUOrdinaria and RUEmergenza: External Tag, Origins, Impact, Host Link, Host Links Notes, urgency, Kind of release, External Release code, Application to release TechnicalActivity: Environment, Operation type, When execute operation. Between work items could be defined different kind of link. In CCRM project the following link-type have been used: Correlated: links two RU which are compiled and released together Blocks/Depends on: link a Technical Activity to RUs. The links are : TechnicalActivity depends on RU or RU Blocks TechnicalActivity. These links could be used both for RUOrdinaria than RUEmergenza

10 Versioning configuration Elements versioning is managed by RTC built on component Every Project Area have two different logic environment (streams): PRACD_Rilascio: it contains all the elements related to production physical environment PRACD_Collaudo: it contains all the elements related to test physical environment PRACD_Integrazione: it contains all the elements related to integration physical environment, or, alternatively, it could be used as logical integration point for team of developers. It could be used only by CM processes. Every stream contains one or more components that are used to divided code in competence areas. The number and the name of these components depends from the process model: CM every stream contains two components PRACD_Src: it contains source files PRACD_Bin: it contains binary files DM every stream contains a single component PRACD : it contains binary files

11 Build RTC provides a set of useful tools to perform automatic source compilation It is possible to define a build engine that permits to a remote server (on which has to be installed RTC Build Toolkit) to download files contained in components and performs operations. The list of operations to be performed are defined from a Build Definition created in the project area. This Build definition could launch different compilation script as Ant, Maven or command line commands. Every Build Definition Is associated to one or more build engine on which could be performed Can be scheduled using RTC scheduler Could contains custom property which can be modify at build launch Defines the workspace repository and the components from which to download files Defines every parameters used to launch the build script

12 Roles Every user added to a Project or a Team area must have a role The roles define permission grant to users and the process behavior for operation performed by users In CCRM project has been defined 5 different roles Developer : generic user who performs standard operation of versioning and change workflow state Applicative Leader: user with more privileges than developer, it could authorize deliver in production environment of change-sets Schedulers: user who authorizes and schedules deploy operation in production environment System Technical User: user who performs manual technical activity described by Technical Activity work item Administrator: user who can performs every activity. For this role no controls or behavior on workflow are performed

13 Architecture overview

14 Adding functionality to RTC Eclipse plugin extension could be used to add functionality to RTC In order to support all the extension described on previous slides, in CCRM project has been created a specific plugin that add link types different from standard: CSDeliveredInCo : it links the change-set delivered into test stream to the RU work item. CSDeliveredInRil : it links the change-set delivered into production stream to the RU work item. This kind of plugin does not need specific code but can be defined using only the plugin.xml file

15 Plug-in development for RTC The plug-ins which provides the operation used in process behavior have been developed using RTC source code as example and sdk. In order to develop plug-ins is necessary to set the Eclipse develop environment following RTC SDK instructions. The plug-ins developed for CCRM project perform the following operations: Check rules on work-item properties (state, attribute values, links) Automatic change of state Automatic build launch The extension points used are the following: com.ibm.team.process.service.operationadvisors : develop pre-condition com.ibm.team.process.service.operationpartecipants : develop post-operation com.ibm.team.process.service.eventhandlers : develop event trigger action com.ibm.team.repository.linktypes : create new link type

16 Agenda Why do we need a Change Management process? Solution overview Project framework Results

17 Project schedule Tasks Process analysis Environments setup Customization Training Go live pilot applications Go live 75 applications Support 06. Jul 13. Aug Sep Oct Nov Dec Nexen IBM Nexen Nexen IBM and Nexen

18 Results Rollout of 80 applications for more than 60 users. 49% of applications CM (38) and 51% DM (40). ORACLE VisualBasic 8 7 ASP JAVA.NET Planned Active 15-ott 22-ott 29-ott 5-nov 12-nov 19-nov 26-nov 3-dic 10-dic 17-dic 24-dic 31-dic

19 Results