-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release automation design - Tier 1 #4710
Comments
|
QA - Release Protocol: Phase 1Wazuh version: version synchronization
|
QA - Release Protocol: Phase 1Wazuh version: version synchronizationSupport a new stage for a specific version in the
|
QA - Release Protocol: Phase 1Wazuh version: version synchronizationSupport a new stage for a specific version in the wazuh-jenkins repository.
|
QA - Release Protocol: Phase 1Wazuh Packages: Creating Packages
Each task is in a new pipeline to release everything as a set, and if there are failures, the pipeline should stop and send a message to c-release reporting the new problem. However, each subtask will consist of launching and reporting but the main task of building packages, images or verifying the checksum is another task that will be covered by another script or pipeline that needs to be defined.
|
QA - Release Protocol: Phase 1Wazuh Resources: Providing the Demo Environment
|
QA - Release Protocol: Phase 1Wazuh Testing: Test Plan
|
CONCLUSION - Phase 1:
|
Description
In the releases process there are tasks that are repeated with some changes without complexity.
Therefore, we have decided to automate the process as much as possible. To begin with, you need to research the process in detail.
Once we start this, it will help us reduce execution time and members involved.
Functional requirements
The QA team will try to identify each task. If it corresponds to another team, it will request that it be automated.
The QA team will try to integrate the tasks with Jenkins and thus automate the different actions that are currently carried out manually. (Actions detailed in the tasks section).
The QA team will define a new framework for E2E test development. This will help us to reduce the number of teams involved to run them.
Non-functional requirements
Implementation restrictions
Each script and test must include an analysis and report.
At the end of each task, it should automatically send a message to the
c-release
channel so that those responsible can analyze the results and, if it fails, try to solve it or create an issue to investigate.The members involved must have the necessary permissions and resources to work without delays.
Plan
Release Protocol: Phase 1
Release Protocol: Phase 2
Release Protocol: Phase 3
Tasks
Release Protocol: Phase 1
Wazuh version: version synchronization
Description: Create tag of the new version.
Wazuh Packages: Creating Packages
c-release
channel. Packages to create:Wazuh Resources: Providing the Demo Environment
Wazuh Testing: Test Plan
Release Protocol: Phase 2
Wazuh test: regression
Release Protocol: Phase 3
Wazuh version: Branch maintenance with the latest changes.
|- wazuh-qa
|- wazuh-jenkins
|- wazuh-automation
|- wazuh- packages
|- wazuh
|- wazuh-ansible
|- wazuh-docker
|- wazuh-puppet
|- wazuh-kubernetes
|- wazuh-splunk
|- wazuh-dashboard-plugins
|- wazuh-documentation
Wazuh Resources: AWS Update
Wazuh Release: Define the final tag and final Release Notes.
Generate final tag and publish the darft of releases. It includes:
|- wazuh-qa
|- wazuh-jenkins: update shared, restore shared libraries.
|- wazuh-automation
|- wazuh- packages
|- wazuh
|- wazuh-ansible
|- wazuh-docker
|- wazuh-puppet
|- wazuh-kubernetes
|- wazuh-dashboard-plugins
|- wazuh-documentation
Publish Release
|- Send AMI to analysis
|- Launch publish release without unattended
|- Launch unattended
|- Build and release debug packages
|- Build and push docker hub images
|- Publish AMI
|- Invalidate cache in lives --> AWS Cloud Cache
Check Lives packages
|- check production with files present
|- deploy wazuh installation assistant and check version.
|- AMD64 live installation test.
|- WPK version checks
|- WPK upgrade
|- Ami published
|- Puppet forge module published with latest version.
|- Docker images published.
Wazuh Validation: Sanity Tests
Wazuh Sync: Clear branches, tags, and release notes.
|- Merges desde rama actual a master
|- Publish as latest
|- Delete all pre-releases
|- Remove all tags not el definitivo
|- delete branch y no tag
|- Check tag y releases notes.
|- Merges desde actual a master
|- Publish as latest
|- Delete all pre-releases
|- Remove all tags not el definitivo
|- delete only the branch
|- Update Docker hub readme compatibility matrix
|- Delete stages
|- Check tag y releases notes.
|- Publish as latest
|- Delete all pre-releases
|- Remove all tags not el definitivo
|- delete only the branch
|- publush demo.com with new version
|- Check tag y releases notes.
|- Merges desde rama actual a master
|- Publish as latest
|- Delete all pre-releases
|- Remove all tags not el definitivo
|- delete only the branch
|- Update Jenkins configuration with new version.
|- Build release containers.
|- Update test_nightly parameter.
|- Check tag y releases notes.
Wazuh Resources: Regeneration of demo environment and Jenkins.
|- From current version to master.
|- Demo environment
|- Build Jenkins images
Wazuh Publication
Note:
Case 1:
Case 2:
The text was updated successfully, but these errors were encountered: