1 / 9

Establishing Software Development and Test Environments March 14, 2003

Establishing Software Development and Test Environments March 14, 2003. Development & Testing Areas of Concern For the Backend. Science & engineering data processing (DP) systems Archive ingest & distribution systems Archive user interfaces Science calibration pipelines

jadon
Télécharger la présentation

Establishing Software Development and Test Environments March 14, 2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Establishing Software Development and Test EnvironmentsMarch 14, 2003 Implementation Review

  2. Development & Testing Areas of Concern For the Backend • Science & engineering data processing (DP) systems • Archive ingest & distribution systems • Archive user interfaces • Science calibration pipelines • Calibration reference file generation & registration • Database systems • Operations Tools Implementation Review

  3. Development & Testing Environments Today • Variety of operations environments = variety of development/test environments • Operating systems: Tru64, Solaris, OpenVMS, Windows • OpenVMS hosts some legacy systems not yet ported to UNIX • Appropriate MO jukebox drivers not available under Tru64 (Solaris, yes) • H/W platforms: personal computers, workstations, servers, archive peripherals • Storage: from server-based to centralized • Perennial shortage of disk space resulted in many smaller disk systems spread over many systems • Lack of server consolidation strategy in the past has led to a variety of system architectures and practices for engineering them • Architectural differences and the scope of the various systems is large today • Engineering of each component occurs in relative isolation of other systems (except at interfaces) • Thorough unit and regression testing is not always enough: need capability to do realistic performance and load testing • Some development activity is performed on the operations systems today Implementation Review

  4. Motivation for Migration • Provide full load and performance testing capability • Need systems identical in type, number, and configuration as operations • Reduce number of supported platforms and networked storage volumes • Increased development / test cycle efficiency • Reduce system configuration problems • Reduce data shuffling activity as storage needs change Implementation Review

  5. Migration to Consolidated Server & Centralized Storage: Benefits • Enhanced product quality • True system test environment to permit realistic performance and load testing • More thorough regression testing of calibration pipelines will be possible • Improved efficiency • Reduced number of operations platforms = fewer development/testing environments = less development/testing effort • Centralized storage reduces file shuffling activity by providing adequate and configurable data volume sizes • Common engineering process for many different components on a common infrastructure can be applied Implementation Review

  6. Migration to Consolidated Server & Centralized Storage • Effort is minimal due to existing support for Solaris environment by all backend components • Port from OpenVMS was done to generic UNIX for just such a situation • More thorough testing of components that run operationally under Tru64 at present is underway • Bulk of migration effort involves copying of files • Each developer/tester will move their files and configure their environment once the system becomes available to engineering • Some desktop workstations systems no longer are needed and will be replaced by more typical systems • calibration pipeline development and unit testing moves off of desktop workstations onto server • Common systems development process already in use • Ensures adequate stakeholder involvement at key points in the development cycle Implementation Review

  7. Migration to Consolidated Server & Centralized Storage (cont.) • Development-specific activities • Update build procedures and tasks to support new system (~1 week effort) • Tru64-specific code removed from build scripts • Changes to paths and node names as needed • Editing or deleting text files within several software repositories (~1 week effort) • Nightly builds redeployed to new server • Developers commit S/W changes to repositories, then checkout code again on new system in order to establish new coding environment • Perform verification builds for all components as a sanity check and to support testing transition (~1 day effort) • Some of this activity already underway on the loaner • Mitigates problems with systems at different patch levels (e.g., system header files containing code differences) OSNAME:=$(shell uname) ifeq ($(OSNAME),OSF1) os_sub_dir = axp_unix endif ifeq ($(OSNAME),SunOS) os_sub_dir = sparc_solaris endif Implementation Review

  8. Migration to Consolidated Server & Centralized Storage (cont.) • Testing-specific activities • Full regression and system testing of all backend components using verification builds (~3 week effort) • New system tests for performance and loading each component must be developed that address: (~3 month effort) • Test environment definition for each backend component • Scope of the test • Logistics • Test setup • “Off-test” backend component simulators • Completion criteria • Full system test development will occur in parallel with deployment Implementation Review

  9. Schedule for Transitioning Implementation Review

More Related