Skip to content

Integration_Environment_+_Automated_Tests

Matt Wagner edited this page Oct 25, 2012 · 1 revision

Integration Environment + Automated Tests

Recently we’ve been suffering a lot of integration pain. Much of this could be avoided by a continuous integration environment and frequently running integration tests. This document discusses the high level components involved in creating a system.

Task Overview

  1. Build rpms on code check-in to next
  2. Publish new rpms to an internal yum repo
  3. Update rpms on ‘demo box’ or reprovision entirely
  4. Run automated test suite against ‘demo box’
  5. Report failures
  6. Tag ‘good’ builds
  7. Manage rpm publication to fedorapeople

Components

Orchestrator (Hudson/Jenkins)

  • Monitor repo & kick off all the action
  • May host internal yum repos, or may rsync rpms elsewhere
  • Possibly use hudson’s ability to tag builds retroactively upon success
  • Explore use of mock to build a variety of yum repos.
  • Communicate results via email/irc/redmine

Internal yum repos

  • Need somewhere to host internal yum repos
  • How often do we empty this? How do we know which rpms are good?

Automated test box

  • Configured to know about internal yum repos
  • Updated/available for testing

Demo box

  • We may want some redundancy here, or the ability to have one box more stable for impromptu demos w/o worry about instability from the last automated build.
  • Perhaps only take ‘tagged builds/rpms’
Clone this wiki locally