Approach to development in OTM projects

Transcription

1 Approach to development in OTM projects Anton Moiseev Anastasia Goncharova Amsterdam, March 2014

2 AGENDA What is extension Development problems Solution elements How we use it 2

3 DEVELOPMENT IN OTM PROJECTS Standard functionality What customer wants How we meet customers needs in OTM projects 20% 80% Configuration&Setup Extentions 3

4 TYPES OF EXTENSIONS ERP Integration GUI changes Automation agents, programs and PL\SQL procedures Printing forms Operational Reports 4

5 EXTENTIONS DEVELOPMENT PROBLEMS Manual transfer of extensions between environments Manual testing without regressive testing Different people who develop, test and transfer Probability of critical errors on production system 5

6 STARTING POINT Business-critical system Minimum downtime allowed A lot of extensions in the project Big project team A lot of new requirements after go-live 6

7 WHY WE STARTED TO SOLVE THE PROBLEM (BUSINESS PERSPECTIVE) Probability of violation of the terms of the project Increase project costs Errors in extensions => Additional downtime of the system => Financial Losses 7

8 LIFE IS LIFE 8

9 HOW WE SOLVED THE PROBLEM The main GOAL: Don t break the production! Approach: Using classical approaches in development Solution Elements: 1. Environments 2. Releases 3. Automated process of collecting and installation 4. Automated process of testing 9

10 PROJECT ENVIRONMENTS Updating the environment after successful release on PROD Usually 1 per day update DEV Development Unit testing of extensions Unit testing of setups TEST Integration testing of business-processes Testing builds Performance testing PROD Production 10

11 RELEASES Question: System in production and users want more and more??? Answer: Use releases! Release includes: Settings and configuration changes of the system Extensions Using releases you can: Plan the timing and cost of the project Predict downtime for the system 11

12 AUTOMATED PROCESS OF COLLECTING AND INSTALLATION: GENERAL INFORMATION Solution developed by CROC using Python and PL\SQL internally named HARDCODER. Consist of 2 parts: Collecting module to create build from source OTM environment using predefined list of objects Installation module to update objects on destination OTM environment and create backup of previous version of objects Source OTM Environment Destination OTM Environment Build Backup Configuration files Collecting module Installation module 12

13 AUTOMATED PROCESS OF COLLECTING AND INSTALLATION: WHAT IS BUILD Predefined structure of directories with.sql,.xml,.xsl,.rtf,.jspx files and installation.bat scripts 13

14 AUTOMATED PROCESS OF COLLECTING AND INSTALLATION: ADVANTAGES Elimination of bugs in build process, especially then several iterations of release testing performed Automatic system of collecting and installation ensures that testing is always performed with the same set of modified objects Reduction of time and costs to create and install build 14

15 AUTOMATED PROCESS OF TESTING: GENERAL INFORMATION Testing cluster Web Server Test case (.json file) Testing system based on Java Selenium Hub Selenium WebDriver 1 OTM Selenium WebDriver 2 Testing report Selenium WebDriver N Web application 15

16 AUTOMATED PROCESS OF TESTING: TEST CASE Micro scenario Test case Simple OTM action, for example: creating order release preparing data Consist of 2 elements Testing scenario (GUI actions sequence) Data preparation (.json file) Existing micro scenarios can be used during preparing new test cases Can be positive (without expected error) or negative (expected error) 16

17 AUTOMATED PROCESS OF TESTING: CAPABILITIES Regressive capabilities of testing How to be sure that new extension didn t broke some of previous extension? Data combinations covering How to be sure that new extension works correctly with all significant data combinations? Preparing data for testing How to prepare new data set for testing quickly? 17

18 AUTOMATED PROCESS OF TESTING: WHEN TO USE Regressive testing and checking compatibility with previous extensions is needed A lot of testing iterations Cost of testing Cost of automatic testing Cost of manual tesing Count of testing iterations 18

19 HOW WE USE IT: GENERAL APPROACH Starting conditions business-critical system in production ongoing process of new requirements and bugs fixing Main steps 1. Collect requirements 2. Set priorities 3. Divide to releases 4. Define standard or non-standard functionality 5. Develop and setup 1-st Release 6. Get final build for the 1-st Release 7. Begin tests 19

20 HOW WE USE IT: TEST RELEASE Starting conditions DEV environment = PROD environment Release components are tested on DEV, at the first blush - everything is OK Test cases are created\corrected for new extensions Main steps 1. Create\update configuration file for the build. Run Collecting module on DEV. Creating the build. 2. TEST environment updated from PROD 3. Manual setups on TEST (that are not in the build) 4. Create backup of TEST environment 5. Run Installation module for TEST (transfer build from DEV to TEST) 6. Automatically running of autotests (usually during the night). All new extensions are tested in total. Regressive testing of old extensions is also performed 7. Testing report is automatically prepared 8. If no error PROD can be updated. 9. In case of errors - TEST is restored from backup. Fixing extensions and maybe test cases, go to step 1. 20

21 HOW WE USE IT: TRANSFER RELEASE Starting conditions Release is tested on TEST environment, everything is OK Main steps 1. Run Collecting module on PROD. Create the build of previous version of extensions (extensions backup). 2. In predefined time interval perform manual setups (that are not in the build) on PROD 3. Run Installation module for TEST (transfer build from TEST to PROD) 4. In case of errors - return back manual setups and run Installation module for the build with previous version of extensions. 21

22 WHAT WE GET Minimizing risks of critical errors on PROD Reduced time of development and testing for complex releases 22

23 PLANS TO UPGRADE Automate the process of testing for end-to-end processes Automate the process of transferring changes in setups and properties-files Updating the records and objects according to rules Fully automated system for release s installation 23

24 DOCUMENTATION PROCCESS MD.020 Application Extension Definition and Estimates MD.050 Application Extensions Functional Design MD.070 Application Extensions Technical Design All source codes and scripts of installation are storage in the version control system TFS 24

25 Q&A 26