|
|
|
**Crown Platform Release Process**
|
|
|
|
|
|
|
|
**Version 0.1**
|
|
|
|
|
|
|
|
24/01/2018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Chris Kibble
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Document History**** , Approval & Contributors**
|
|
|
|
|
|
|
|
## 1. Revision History
|
|
|
|
|
|
|
|
| **Version** | **Revised By** | **Date** | **Status** | **Release Notes** |
|
|
|
|
| --- | --- | --- | --- | --- |
|
|
|
|
| 0.1 | Chris Kibble | 24/01/2018 | Creation | |
|
|
|
|
|
|
|
|
## 1.2. Internal review
|
|
|
|
|
|
|
|
| **Role** | **Name** |
|
|
|
|
| --- | --- |
|
|
|
|
| | |
|
|
|
|
| | |
|
|
|
|
| | |
|
|
|
|
|
|
|
|
## 1.3. Document Approval
|
|
|
|
|
|
|
|
| **Role** | **Name** | **Signature** | **Date** |
|
|
|
|
| --- | --- | --- | --- |
|
|
|
|
| | | | |
|
|
|
|
| | | | |
|
|
|
|
| | | | |
|
|
|
|
|
|
|
|
## 1.4. Document Contributors
|
|
|
|
|
|
|
|
The following people contributed to the production of this document:
|
|
|
|
|
|
|
|
| **Role** | **Name** |
|
|
|
|
| --- | --- |
|
|
|
|
| Test Manager | Chris Kibble |
|
|
|
|
| | |
|
|
|
|
|
|
|
|
# 2. Glossary
|
|
|
|
|
|
|
|
| **Abbreviation** | **Full Description** |
|
|
|
|
| --- | --- |
|
|
|
|
| CRW | Crown Platform |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Release Process**
|
|
|
|
|
|
|
|
The nature of the CRW team means that communication and organisation are key aspects of what and how we achieve our goals. This document is to outline the release process so that every stakeholder has visibility of the way we work.
|
|
|
|
|
|
|
|
In order to give everyone a little overview of how important this release process might be I have added an image to specify the importance of every aspect involved.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**What goes in to a release?**
|
|
|
|
|
|
|
|
As Crown is going to be developing on a feature by feature process (Kanban esque) then we'll need to be looking at features per release together and agreeing on each feature.
|
|
|
|
|
|
|
|
The team need to have a specific meeting to discuss this.
|
|
|
|
|
|
|
|
1. Review GitLab backlog to identify and recognise the priority items (bitcore additions? Wallet upgrades? Proposal system fixes?)
|
|
|
|
2. Review any support items from the forum that may have not made it to GitLab (users with sync issues? Setup or tear down of a system node?)
|
|
|
|
3. Collate enough items for a release to satisfy the team
|
|
|
|
4. Review the entire list of items and prioritise items to work on straight away, then secondary items and then nice to haves for the release
|
|
|
|
5. Discuss time frames for each item including development estimates, testing estimates, time to alert exchanges and a finger in the air ready to release date
|
|
|
|
6. Allocate each GitLab issue to specific team members to take care of their items in the release
|
|
|
|
7. Get GitLab up to date with all possible issues, build numbers, build dates and estimated time to completion for the next release
|
|
|
|
|
|
|
|
**Development phase**
|
|
|
|
|
|
|
|
The development process is how the team handles and works together to make sure that what we've all agreed on for the release, makes it to the release in full working order.
|
|
|
|
|
|
|
|
1. GitLab must be updated daily (hopefully we'll start adding hours i.e. Time estimation to complete, time worked on)
|
|
|
|
2. Morning skype meetings with the developers and testers to discuss current work (time boxed to 15 minutes maximum)
|
|
|
|
|
|
|
|
- What I did yesterday
|
|
|
|
- What I will do today
|
|
|
|
- Anything that is stopping you doing your work which needs to be done first
|
|
|
|
|
|
|
|
1. All features being worked on must be in GitLab for team visibility
|
|
|
|
2. All work must comply with the teams "Definition of Done" before being moved on (developers can't push to testers without complying, testers can't set to complete with complying)
|
|
|
|
3. Any new features deemed priority for the release must be discussed and agreed to as the team will most likely have to remove another feature to enable the release to keep to the time frame
|
|
|
|
4. Development builds and test builds must be kept separate in order to avoid time wasting with possible merge conflicts, sync issues in testnet and mining testnet pools
|
|
|
|
|
|
|
|
**Regression Testing**
|
|
|
|
|
|
|
|
Regression testing is a method used to test all aspects of a product of feature before release. Once the development phase is complete then we will enter a phase of regression.
|
|
|
|
|
|
|
|
Regression testing involves:
|
|
|
|
|
|
|
|
1. System testing – testing an item in its singularity i.e. functions of a Crown wallet
|
|
|
|
2. Integration testing – testing multiple items are working together as expected i.e. Crown wallet syncing with a masternode VPS, 2 masternodes being in sync with each other
|
|
|
|
3. Whole team participation – There are so many variables that are required to test that we will need the help of the whole team and we will use a test charter and compatibility matrix (where applicable)
|
|
|
|
4. Testnet stability will be key during this phase in order to collect debug, budget and log files
|
|
|
|
5. If an issue is found during the Regression phase then it will require a fix immediately and testnet may need to be turned off until the fix is implemented and all wallets, masternodes and systemnodes can be updated with the latest test build
|
|
|
|
|
|
|
|
**Release Strategy**
|
|
|
|
|
|
|
|
Our release strategy is a guideline for anything and everything the team must achieve, communicate to or execute in order keep Crown Platform running during an update process.
|
|
|
|
|
|
|
|
This document is currently being worked on by various members, has had input and acceptance across the board and must be adhered to for every release.
|
|
|
|
|
|
|
|
The release strategy can be found on the Crown wiki here:
|
|
|
|
|
|
|
|
http://gitlab.crown.tech/crown/crown-core/wikis/release-steps |
|
|
\ No newline at end of file |
