Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Products go through varying procedures to get released.  It’s important to understand our terminology when communicating outward.  From a 50,000 foot view, the different stages look like:

Development -> Unstable -> Stable (i.e., alfa - In stage folder) -> Release Candidate (i.e., beta - > Release

Before a build is pushed to release, the following steps are performed:

Still in stage folder) -> Release (accepted release copied to download repo) -> Unstable (Release + back-ported fixes - stage folder)   

Our process

  1. Product Management coordinates with support and developers and decides there are bugs, enhancements or new features (these are all broken down into ‘issues’) that need to be delivered to customers.
  2. Product Management determines the issues that will get assembled into a release based on severity, need and desired timeline for a release.
  3. Developers build code to solve the identified issue(s).
  4. Developers test their code and then merge their code into an Unstable build.
  5. Code undergoes testing in Unstable by QA.
  6. QA accepts the code as working or notes issues with it and sends it back to the developer.
  7. Once code is accepted the developer merges the new code into the Stable build.
  8. In the Stable build the new code is tested with all other code new & old.
  9. As significant additions are moved to Stable, eZuce installs Stable build on our internal communications system to work out issues in a production environment.
  10. Once all Issues for a release have been tested in Stable, Product Management informs testing/release engineering to prepare a release candidate.
  11. Release Engineering initiates a Release Candidate build from the Stable code repository.
  12. all of the issues slated for a release are completed the unstable build is smoke tested (quick install and basic functionality tests).
  13. With smoke tests completed, a Beta is declared and announced to customers and to the sipXcom community.
  14. Release Candidate (Beta) is installed on eZuce’s corporate system.
  15. A minimum time of 2 weeks will pass.
  16. Automated Testing team lead coordinates with manual testing team lead on test plan .
  17. Automated testing initiates what is called a smoke test.
  18. Manual testing initiates manual testing according to test plan.
  19. openUC Release Candidate is installed on eZuce’s corporate system.
  20. Automated testing initiates sanity, regression and load tests (take about a week)
  21. and initiates regression tests..
  22. If any regressions or bugs are found, Product Management is consulted and development is consulted for a fix or feature clarification.
  23. If further coding is required it is completed, tested, merged back into stable stage and the process starts again at step 1011.
  24. Once all parties are satisfied with Release Candidate (Beta) the binaries are Released to customers on the appropriate download servers.
  25. Any additional patches back-ported to the release will be built in unstable repository because they are not fully regression tested with the rest of the code.

Explanation of Unstable

...

A Before release this is a build that contains features that are still in development and slated for an upcoming 4.6 release.  Features or bug fixes that make "large" changes are developed on separate code (git) branch called a "feature branch" away from all other code.  Once they pass a certain level of testing, then the branch is merged into the Stable branch.  This allows features to be integrated with the rest of the system code when they are determined to be in a stable state. 

Unstable build code is available to customers for testing from the following binary repositories:

openUC binaries Binaries http://download.ezuce.com/openuc-stage/release-4.6.0-unstable/

Explanation of

...

Stable builds are essentially the precursor to a Release Candidate. These builds represent the most stable code produced by development to their knowledge. The Stable build includes all bug fixes and any features that have passed an initial testing process.  The fixes and features may not however been tested with the system as a whole.

Stable build code is available to customers for testing from the following binary repositories:

openUC binaries : http://download.ezuce.com/openuc-stage/release-4.6.0-stable/

Explanation of Release Candidate:

Release Candidate (beta)

Once a Release Candidate (beta) build is chosen, it goes through an outlined regression testing process.  If no regressions are found during the testing process, the exact set of binaries are copied to the appropriate release directory and user and customers are notified.  If bugs are found that are not regressions, release process can continue as normal depending on what the bug is.  This decision to continue with a known bug is up to Product Management.

Release Candidate code is available to customers for testing from the following binary repositories:

openUC binaries Binaries http://download.ezuce.com/openuc-stage/stage/4.6.0

Note:

Please contact an eZuce Solutions Architect for user and password required for pre-release builds. 

Explanation of Release

Release builds are accepted Release Candidates (Beta). These builds represent the most stable code produced by development to their knowledge. The Release build includes all bug fixes and any features that have passed the regression testing process and that no outstanding known bugs have been introduced.

Release build code is available to customers for testing from the following binary repositories:

Binaries : https://download.ezuce.com/openuc

Patches on top of Release

Any patches that are added to a release are only added to the stage (unstable) repository. We reuse that repository area so that we don't need to re-create a new one. It's important to note that this repository and the fixes applied are not fully regression tested.

Binaries : http://download.ezuce.com/openuc-stage