Tizen Release Management

From Tizen Wiki
Jump to: navigation, search

See more at Platform Development.

Mission

Release Engineering concerns releasing software in a controlled process that results in high-quality software that is useful to developers. High quality is determined by a set of tests that a release engineer, the person in charge of providing a release, runs on an image that contains approved, code-reviewed changes to the build. If it passes, those changes will be processed; otherwise they will be rejected.

In Tizen, we have release engineers who guide the changes produced by developers into the production build for each vertical. Release engineers employ smoke tests on each build they are responsible for to make sure that the build passes a minimum testing called smoke tests before extensive testing is done by the QA team.

Daily Activities of Release Engineering

Release engineering is the heart of the development cycle. It provides robust images that are the baseline for continuing development, as well a central point of contact. Without release engineering, a project will lose a valuable source of stability and information. The release team has the final say on what goes and what doesn't go into a build.

On a daily basis, release engineers process changes that come from development through Gerrit and Jenkins services. These images are tested on appropriate hardware according to the project a release engineer is assigned to. For instance, for Mobile, a release engineer will have access to a wide variety of phone devices to test the image on. If there are issues with the image, the release engineer will do some rudimentary debugging in order to discover the problem. The release engineer will also contact developers or domain owners of the change in case a change causes instability.

Once a change or many changes are approved, a snapshot build is created and is again tested for robustness. Once defined smoke tests are passed, a release engineer promotes that image to an official image and it is copied to a release area. The release engineer will then send out an announcement of an official build with an associated release notes based on a template.

After the announcement, QA will start testing the build and issue their own quality reports based on that image. The image then will be the new baseline for development. The next day the process starts again.

Processes

Release Engineering requires some established processes. These processes are decided by the Build, Release, Operations (BRO) team. These processes cover everything from how the build system is used, process to accept a change, format of an image name and so forth. We will try to document these processes as extensively as possible.

  • Release Engineering Processes
    • Release Cadence - Every vertical has their own release cadence based on how they do development. A release cadence indicates a schedule of releases for the life of a project.
    • Image types - Documents the kind of images that are created.
    • Image Naming Convention - The naming convention of the images that are created by the build system.
    • Image Retention polices - How long we keep our images around.