1 / 8

Release Beta Build and Deployment Testing

Release Beta Build and Deployment Testing. Builds Name. Alpha Naming convention: 0_1_X HEAD Naming convention: HEAD Beta Naming convention: 0_2_X Always the same subsystem/components configurations until release candidate ? at least at this stage we should lock the RC configuration !.

ernestwilkins
Download Presentation

Release Beta Build and Deployment Testing

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. Release BetaBuild and Deployment Testing

  2. Builds Name • Alpha • Naming convention: 0_1_X • HEAD • Naming convention: HEAD • Beta • Naming convention: 0_2_X • Always the same subsystem/components configurations until release candidate ? • at least at this stage we should lock the RC configuration !

  3. Builds Execution • HEAD configurations: • Project builds scheduled nightly • BETA configurations: • Project builds scheduled nightly • Subsystem integration builds by request • method1: submit link in build report webpage • method2: ask Alex • Infrastructure • local build: grids16.eng.it • remote build: only possible if etics remote build can publish artifacts in a protected repository

  4. Deployment Testing Execution • Libraries: automatic • Services: based on the deploy test tool • REQ: service undeployment in DL Management • REQ: get service ID from service name in PR • Portlets: deployment script needs to be provided • Infrastructure • local tests (remote test can also be tested) • independent infrastructure

  5. Schedule • Expected execution times: • Build full project: ~4 hours • Build individual subsystems: ~1 hour • Deploy test project: ~6 hours (services only!) • However: • fixing bugs requires some time: • Even using Savane to set up the bugs publication • Even with normal developer support • time needed to run deployment test in portlets is unknown • Major progresses at least = 1 week

  6. Alpha Beta Number of weeks to produce RC 8 6 Number of components 89 151 Number of integrations configurations 4 6 Schedule • 12/03: org_diligentproject_0_2_0 • 19/03: org_diligentproject_0_2_1 • ... • 16/04: org_diligentproject_0_2_5 (last comp. integrated) • 23/04: org_diligentproject_0_2_6 (possible RCB)

  7. Repositories • Build Server (grids16.eng.it) • Stores all different BUILDs of all configurations • Should not be available to the public • Services, Libraries, Portlets and Service Archives • Repository (grids17.eng.it) • Stores the last BUILD • Used by the deployment testing • Services, Libraries, Portlets and Service Archives • Distribution Repository (grids16.eng.it) • Not integrated with DILIGENT Portal • Independent access control

  8. Logistics • Clarify developers about: • how to declare their services available • change Savane status field to “Done” • create an ETIC configuration and associate it with the subsystem conf. • bug fixing strategy • bug fixing is done on HEAD, a new tag created, the conf. updated • the naming rules to be used • usage of ETICS client • (set up a TCom conf call to explain) • Have 1 weekly phone call (on Fridays) • summarize the progresses of the week (ALL) • present the components to be included in next week integration build (ENG)

More Related