automated migration & release and migrations management

8/2/2019 Automated Migration & Release and Migrations Management

1/92

Automated Migration &Release and Migrations

Management

Please consider the environment before printing this document.


2/92

86069748

Functional Design

Extension

Use: Internal

Unit Code: Insertar cdigo

Version: 1.0

FECHA: 27/02/12

Document Change Control and approval

Update this table when changes are made to this document.

Distribution List

Copyright 2011 ACCENTURE.All Rights Reserved.

Print: 25/05/2011 Page 2 of 92


3/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Index

1. Overview

1.1 General Needs1.2 Purpose of the document


Print: 25/05/2011 Page 3 of 92


4/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

2. High Level Requirements

2.1 Release Management

2.2 Automated Migrations & Migrations Management

3. Tasks & Estimation


Print: 25/05/2011 Page 4 of 92


5/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 5 of 92


6/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 6 of 92


7/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

1. Overview

1.1General needs


Print: 25/05/2011 Page 7 of 92


8/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Nowadays, all release and migration management at NH is made manually.Releases are managed through a set of ms excel documents that areupdated by development lead and people involved in the development.Migrations are managed by a similar mechanism. The major problem we arefinding at NH is the migration process, by which we have to be sure thatevery item is

1.2Purpose of this document

In this document we are going to explain the result of the application we areabout to develop. For the two types of management we want to do throughthis application, we are going to explain how all users related to the process


Print: 25/05/2011 Page 8 of 92


9/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

are going to interact with the application and how is the application going tobehave. Finally we are going to make a list of different tasks that will benecessary to be developed, and the initial estimation for them.

2. High Level Requirements

2.1Release Management

We would like to build this part of the application in order to manage thedelivering of the units that are being developed in NH for all areas.


Print: 25/05/2011 Page 9 of 92


10/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Nowadays, it is been managed through a set of excel documents, nothingautomated that is improving defects and confusing between the differentpurposes of the documents. With this tool, we are about to give a differentset of roles access to update and manage delivering.

There are the following roles that will be using the form: Functional Responsible Functional Lead NH IT Responsible Development Lead IDC Development Lead IT Responsible Administrator


Print: 25/05/2011 Page 10 of 92


11/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Depending on the role the user who is entering the application has, he/shewill have access to different parts of the application.

2.1.1 Development LeadThe development lead will enter all the components in scope fordevelopment and/or String test. Initially, the release will be empty and thedevelopment lead has to complete the details:


Print: 25/05/2011 Page 11 of 92


12/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 12 of 92


13/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The development lead will fill the following fields: CR: Change request. Only if the CR number has been given. If it has

not been given, this can be updated afterwards. Unit Code: It is the technical component code. This must be created

before entering it by the development lead in the unit managementform.

Status: Overall status for the component. The possible statuses are:1.NOTSTARTED2.INPROGRESS3.COMPLETE


Print: 25/05/2011 Page 13 of 92


14/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

4.APPROVED5.ONHOLD6.CANCELLED7.DEFERRED

Priority: It is the priority for the unit. The priority should be: 4 (Low)

3 (Medium)

2 (High)

1 (Critical)

Complexity: It is the complexity for the unit. This should be assed inconjunction with the development lead. The complexity should be: 4 (Low)


Print: 25/05/2011 Page 14 of 92


15/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

3 (Medium)

2 (High)

1 (Very High)

The release manager, the development lead and the administrator andthe only roles that can create or delete records, so all the other roles canonly update their tab or add comments or issues.

2.1.2 Functional responsible:

The Functional Responsible role includes Functional design delivery planning

and control of the delivery. So, basically this role will update the Functionaldesign Tab:


Print: 25/05/2011 Page 15 of 92


16/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 16 of 92


17/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The Functional responsible will fill the following fields: FD Owner: Functional resource that will update the functional design. FD Status: Delivery status of the functional design. The possible

statuses are:1.NOTSTARTED2.INPROGRESS3.COMPLETED4.APPROVED5.ONHOLD6.CANCELLED


Print: 25/05/2011 Page 17 of 92


18/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Planned Duration: Number of days that it is estimated will take thefunctional design update.

Planned start date: plan start date for the functional designer to startworking on it.

Planned end date: planned finish date for the functional design to becompleted. It is automatically calculated base on the plannedduration and planned start date fields. This will help very much thefunctional lead.

Actual start date: The date the functional designer has startedworking on a functional design update.

Actual end date: the date the functional designer has completed thefunctional design.


Print: 25/05/2011 Page 18 of 92


19/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The functional responsible additionally can enter issues or comments to aspecific record by clicking in the comments and issues button:


Print: 25/05/2011 Page 19 of 92


20/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 20 of 92


21/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The issue text is first entered including the issue. When it is solved theresolution should be entered and the Resolved flag updated.

2.1.3 IDC Development Lead

The IDC Development Lead role includes Technical design, build, unit testingand Acceptance Test delivery planning and control of the delivery. So,basically this role will update the TD, Build, Unit test and AT Tabs.

TD tab:


Print: 25/05/2011 Page 21 of 92


22/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 22 of 92


23/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The IDC Development lead will fill the following fields in the TD tab: TD Owner: technical resource that will update the technical design. TD Status: Delivery status of the technical design. The possible

statuses are:1.NOTSTARTED2.INPROGRESS3.COMPLETED4.APPROVED5.ONHOLD6.CANCELLED


Print: 25/05/2011 Page 23 of 92


24/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Planned Duration: Number of days that it is estimated will take thetechnical design update.

Planned start date: plan start date for the technical designer to startworking on it. It is automatically defaulted from the FD Planned enddate.

Planned end date: planned finish date for the technical design to becompleted. It is automatically calculated base on the plannedduration and planned start date fields.

Actual start date: The date the technical designer has started workingon a technical design update.

Actual end date: the date the technical designer has completed thetechnical design.


Print: 25/05/2011 Page 24 of 92


25/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Build tab:


Print: 25/05/2011 Page 25 of 92


26/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 26 of 92


27/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The IDC Development lead will fill the following fields in the Build tab: Developer: Developer that will update the code. Status: Delivery status of the code. The possible statuses are:

1.NOTSTARTED2.INPROGRESS3.COMPLETED4.APPROVED5.ONHOLD6.CANCELLED

Planned Duration: Number of days that it is estimated will take thecode update.


Print: 25/05/2011 Page 27 of 92


28/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Planned start date: plan start date for the developer to start workingon it. It is automatically defaulted from the TD Planned end date.

Planned end date: planned finish date for the code to be completed. Itis automatically calculated base on the planned duration and plannedstart date fields.

Actual start date: The date the developer has started working on acode update.

Actual end date: the date the developer has completed the build.

Unit test tab:


Print: 25/05/2011 Page 28 of 92


29/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 29 of 92


30/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The IDC Development lead will fill the following fields in the Unit test tab: Test Responsible: Tester that will unit test the code. Status: Delivery status of the unit test. The possible statuses are:


Planned Duration: Number of days that it is estimated will take theunit test.


Print: 25/05/2011 Page 30 of 92


31/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Planned start date: plan start date for the developer to start workingon it. It is automatically defaulted from the Build Planned end date.

Planned end date: planned finish date for the unit test to becompleted. It is automatically calculated base on the plannedduration and planned start date fields.

Actual start date: The date the tester has started working on a unittest.

Actual end date: the date the tester has completed the unit test.

AT tab:


Print: 25/05/2011 Page 31 of 92


32/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 32 of 92


33/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The IDC Development lead will fill the following fields in the AT tab: AT Responsible: AT person that will AT the code. Status: Delivery status of the AT. The possible statuses are:


Planned Duration: Number of days that it is estimated will take theAcceptance Test.


Print: 25/05/2011 Page 33 of 92


34/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Planned start date: plan start date for the AT person to start workingon it. It is automatically defaulted from the Unit test Planned enddate.

Planned end date: planned finish date for the Acceptance test to becompleted. It is automatically calculated base on the plannedduration and planned start date fields.

Actual start date: The date the AT person has started working on anacceptance test.

Actual end date: the date the AT person has completed theacceptance test.


Print: 25/05/2011 Page 34 of 92


35/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The development lead additionally can enter issues or comments to aspecific record by clicking in the comments and issues button:


Print: 25/05/2011 Page 35 of 92


36/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 36 of 92


37/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The issue text is first entered including the issue. When it is solved theresolution should be entered and the Resolved flag updated.Additionally, the IDC development lead can enter new records in theGeneral release tab. As they work very close to Development Lead, theymaybe helping them.

2.1.4 IT Responsible

Once the development has been delivered to the on-site team, it will bemigrated to test instance (check next section) and there will be a IT


Print: 25/05/2011 Page 37 of 92


38/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

responsible that will perform a set of tests to be sure the development meetrequirements.

The IT Responsible role includes Integration test delivery planning andcontrol of the delivery. So, basically this role will update the Integration test

Tab:


Print: 25/05/2011 Page 38 of 92


39/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 39 of 92


40/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The IT Responsible will fill the following fields: Testing responsible: Testing resource that will update perform

integration test. Status: Delivery status of the integration Test. The possible statuses

are:1.NOTSTARTED2.INPROGRESS3.COMPLETED4.APPROVED


Print: 25/05/2011 Page 40 of 92


41/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

5.ONHOLD6.CANCELLED

Planned Duration: Number of days that it is estimated will take theintegration Test.

Planned start date: plan start date for the tester to start working on it.This will be defaulted from String test planned end date or from ATplanned end date in case it is empty.

Planned end date: planned finish date for the integration test to becompleted. It is automatically calculated base on the plannedduration and planned start date fields.

Actual start date: The date the tester has started working onintegration test.


Print: 25/05/2011 Page 41 of 92


42/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Actual end date: the date the tester has completed the integrationtest.

The IT Responsible additionally can enter issues or comments to a specificrecord by clicking in the comments and issues button:


Print: 25/05/2011 Page 42 of 92


43/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 43 of 92


44/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The issue text is first entered including the issue. When it is solved theresolution should be entered and the Resolved flag updated.

2.1.5 NH IT Responsible

Once IT Responsible has finished the task, and IT is completed, will be ableto enter to Request Approve form. There, will be able to request approve forIT to the NH IT responsible associated to the development. This, will send anemail to this person with the link to the svn IT document.


Print: 25/05/2011 Page 44 of 92


45/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

It NH IT Responsible gives his OK to the IT, he/she will enter the tool and willclick on accepted flag for the IT form.Only developments with this flag marked will be able to be migrated toProduvction environment

1.1Automated Migration & Migration Management

We need an application integrated with svn and unix servers where we aregoing to manage all code extensions and migration to different instances.

To perform this, we are going to use the developed migration managementforms and we have to develop the integration between them and svnrepository and between both and unix servers.


Print: 25/05/2011 Page 45 of 92


46/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Also we will have to include several scripts that will migrate all needed codedepending on the type of file we need to migrate. Nowadays, NH managethe next list of object types:

OBJECT TYPE OBJECTEXTENSION

MIGRATIONTYPE

Report .rdf Caliente

Form .fmb Frio

Package .pkb, .pks, .pkg, .sql Frio

Script sql .sql CalienteJava class .class Frio


Print: 25/05/2011 Page 46 of 92


47/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Jsp files .jsp Frio

XML files .xml Frio

Softlinks .prog Frio

Workflow .wft FrioProcedures .prc Frio

Concurrents .ldt Frio

Templates DataDefinitions

.rtf Caliente

Alerts .ldt Frio


Print: 25/05/2011 Page 47 of 92


48/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The process idea is the next:1. Development lead inserts a new change that has to be developed.

2. Developer asks for a checkout of the correspondent files that have to

be modified.

3. Application will take the files from the Prod folder from the

correspondent unit folder at svn and will send it to the requester.

4. Developer will work with it and after that will ask for a check in of this

code.


Print: 25/05/2011 Page 48 of 92


49/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

5. Application will load it to the Dev folder from the correspondent unit

folder at svn and will send an email to the requester informing that

deployed has been made succesfully.

6. When it is ready to be migrated, functional responsible will ask for the

migration. Will have to select a list of all files that have to be

migrated.

7. AT person will pass the test for the correspondent migration.

8. If the change has passed the AT, will be ready to be migrated.

9. Migrator will access the application and will start launching everymigration.


Print: 25/05/2011 Page 49 of 92


50/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

10.For every migration, the application will take the files and will launch

the correspondent scripts to install them to the selected instance.

11.If the migration has ended successfully, the application will move the

files from the Dev folder to Pre folder at the corresponding unit folder

(from pre to prod if we are migrating to this instance)

The next diagram explains the global lilefycle of our code:


Print: 25/05/2011 Page 50 of 92


51/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 51 of 92


52/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 52 of 92


53/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The next image illustrates this process:

Insert New changefor an unit

Checkout of thefile

Exists file ?

Yes

New file creationat svn repository

Send all files fromsvn to developer

Check in request

For every object


Print: 25/05/2011 Page 53 of 92


54/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Insert New changefor an unit

Checkout of the

file

Exists file ?

Yes

New file creationat svn repository

For every object


Print: 25/05/2011 Page 54 of 92


55/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

People that are going to use this application:

Development Lead

Developer

Functional Responsible

AT

Migrator

Depending on the role of the person that is entering the application, she/hewill have access to different functionalities.


Print: 25/05/2011 Page 55 of 92


56/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Detailed steps:1. Development lead inserts a new change that has to be developed. He

will provide the developer name.


Print: 25/05/2011 Page 56 of 92


57/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 57 of 92


58/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

2. Developer asks for a checkout of the correspondent files that have to

be modified.


Print: 25/05/2011 Page 58 of 92


59/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 59 of 92


60/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 60 of 92


61/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 61 of 92


62/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

3. Application will take the files from the Prod folder from the

correspondent unit folder at svn and will send it to the requester.


Print: 25/05/2011 Page 62 of 92


63/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 63 of 92


64/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

4. Developer will work with it and after that will ask for a check out of

this code.


Print: 25/05/2011 Page 64 of 92


65/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 65 of 92


66/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

5. Application will load it to the Dev folder from the correspondent unit

folder at svn and will send an email to the requester informing that

deployed has been made succesfully.


Print: 25/05/2011 Page 66 of 92


67/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 67 of 92


68/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

6. When it is ready to be migrated, functional responsible will ask for the

migration. Will have to select a list of all files that have to be

migrated.


Print: 25/05/2011 Page 68 of 92


69/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 69 of 92


70/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

7. AT person will pass the test for the correspondent migration.

The AT member receives an email notification to Acceptance Test thecode. By clicking in Pending Checkout/In/AT button he can check thequeue of pending checkout and AT:


Print: 25/05/2011 Page 70 of 92


71/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 71 of 92


72/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The AT person will retrieve the migration that he needs to acceptancetest, will perform the acceptance test and flags the files that will theversions of the files to be checked in:


Print: 25/05/2011 Page 72 of 92


73/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 73 of 92


74/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

The AT person clicks in Check out/in/AT button, and the clicking in ATAccepted flag:


Print: 25/05/2011 Page 74 of 92


75/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 75 of 92


76/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

This will automatically generate an email that will be sent to thedeveloper, AT, development lead and functional responsible:


Print: 25/05/2011 Page 76 of 92


77/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 77 of 92


78/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

8. Migrator will access the application and will start launching every

migration.

Once the change has passed the AT, the migrator receives an emailnotification. The migrator accesses the Migrations form. The migratorchecks the pending migrations clicking in Pending Migrations button:


Print: 25/05/2011 Page 78 of 92


79/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 79 of 92


80/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Then, the migrator retrieves the migration using the migration id or theunit code and presses the migration request button.

10. For every migration, the application will take the files and will launch

the correspondent scripts to install them to the selected instance. To

do this, will have to perform some steps:

a. Take files from Dev/Pre folder at svn

b. Deploy them at Unix Pre/Prod server

c. Launch the correspondent script for every code file.


Print: 25/05/2011 Page 80 of 92


81/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

11.If the migration has ended successfully, the application will move the

files from the Dev folder to Pre folder at the corresponding unit folder

(from pre to prod if we are migrating to this instance)

Additionaly, information about migration will be updated at MigrationsManagement Form, explaining date and checking flag that it has beensuccessfully migrated.


Print: 25/05/2011 Page 81 of 92


82/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 82 of 92


83/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 83 of 92


84/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 84 of 92


85/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

If the migration has any problem, the migrator should check themigration rejected flag.


Print: 25/05/2011 Page 85 of 92


86/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

3. Tasks & Estimation

We have divided the development of the whole application is threedifferent phases with several tasks:

Phases:Phase 1. Release and Migration Management


Print: 25/05/2011 Page 86 of 92


87/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Task 1.1. Definition of new forms to be developed.Task 1.2. Analysis & DesignTask 1.3. Build & integration of new forms.Task 1.4. Test

Phase 2. Integration of svn repository to the management application.Task 2.1. Updated of svnTask 2.2. Development of interface between svn and application

Subtask 2.2.1 Analysis & DesignSubtask 2.2.2. Build & integrationSubtask 2.2.3 Test

Task 2.3. Application extension to perform check out of documentsSubtask 2.3.1 Analysis & Design


Print: 25/05/2011 Page 87 of 92


88/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

Subtask 2.3.2. Build & integrationSubtask 2.3.3 Test

Task 2.4 Application extension to perform check in of documentsSubtask 2.4.1 Analysis & Design

Subtask 2.4.2. Build & integrationSubtask 2.4.3 Test

Phase 3. Automation of Migration processTask 2.5


Print: 25/05/2011 Page 88 of 92


89/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 89 of 92


90/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 90 of 92


91/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12


Print: 25/05/2011 Page 91 of 92


92/92

86069748

Functional Design

Extension

Use: Internal


Version: 1.0

FECHA: 27/02/12

automated migration & release and migrations management

Documents