Meant as a starting point for a discussion. Lets agree on wich parts that we want/need to have.
Requirements
Clear rules for semantic versioning
Clear documentation of changes
main trunk has to be stable
Pre-release Checks: Define a checklist of pre-release validations, including performance, security, and usability tests, to ensure quality
Release Notes: Prepare comprehensive release notes for each version, detailing new features, improvements, and bug fixes for customers.
It has to be clear which version of the code belongs to a release
Clear rollback strategy
Clear delivery process (includes providing of artifacts and communication to the customer)
migration concept
mainly changes to the db after changes to the schema → db migration task in sf
Steps
Agree on rules for semantic versioning. Suggestion:
Major Version (X.0.0): Increment for incompatible API changes or major changes that require backward-incompatible adjustments by the user.
Minor Version (0.X.0): Increment for adding functionality in a backward-compatible manner.
Patch Version (0.0.X): Increment for backward-compatible bug fixes that do not add new features but fix existing functionality.
Pre-release and Build Metadata: Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format (e.g. -dev)
Documentation of changes. Suggestion:
feature/fix branches for everyone (including frontend)
changelog.md file in repo
maintained by each dev with each PR
can be used for release notes
only concise information about the changes
Release notes:
Agree on a fixed structure for all upcoming releases (we already have something but lets explicitly agree)
use changelog for info about changes
written for the customer to understand new features and bugfixes → can contain more information and explenations about features (may also include background info for example)
Clean trunk based development
short lived feature branches: → sometimes difficult atm because we currently work at complex features
Testing & validation before each merge: → currently only possible by locally by hand. Suggestion: Pipeline for each PR and merge only possible after successful run→ ensures successful tests and build. Short lived deployment would also be possible (more steps needed).
Code review before each merge: → not possible for the frontend
endpoint “versioning” to ensure that the whole application stays stable even with changes that would break the backend frontend communication → new and breaking change is provided on a new and separate endpoint (was done for storage location)
a clear mechanism for this is needed if we expect to use this more often
each merge into the main trunk goes through pipeline and is automatically deployed:
backend testing, automatic build and deploy already in place
automatic regression tests would make sense with the growing complexity of the application
release branch / release tags to clearly identify code version that is delivered to the customer
agreement needed how to handle hot fixes
Rollback strategy
older releases should stay available
At the beginning with bosch as the only customer, this is out of our hands
Maybe we can think about a data backup strategy so we can recommend something to bosch to prevent problems once we are in production
Pre release checks possible checks - lets agree on what we want to have:
Code Review: Ensure all changes have been reviewed and approved by qualified team members.
could be ensured with repo restrictions (no pushing to main, no merging without approval) → currently not possible for frontend
Unit Testing: Verify that unit tests cover new features and bug fixes, and all tests pass.
backend: partially done with api-integration tests
frontend: no tests atm
Integration Testing: Ensure components work together as expected and the system functions correctly as a whole.
backend: partially done with api-integration tests
frontend: no tests atm, sometimes testing by hand
Performance Testing: Assess system performance under expected load conditions to ensure it meets requirements.
currently no mechanism in place
Security Testing: Conduct vulnerability assessments and security scans to identify and fix security flaws.
automatic pen testing is on its way (Patrick)
dependency monitoring on github
Usability Testing: Validate user interface and user experience improvements for intuitiveness and ease of use.
done by hand
Regression Testing: Check that new changes haven't adversely affected existing functionality.
backend: partially done with api-integration tests
frontend: no tests atm, sometimes testing by hand
Final Build: Confirm the final build of the release branch/tag is ready for production, with all features integrated and all tests passed.
backend tests have to pass, rest is done “by hand”
Have a dedicated Deployment with the final build
useful to do some of the above mentioned checks
useful for demo/sprint review
useful to have a env that mirrors the customers env → reproduce errors, communicate functionality etc.
Clear delivery process. Suggestion:
pre release checks (the ones that we agreed on at that point) passed
Release notes are ready
written
reviewed & approved
Artifacts of final build pushed to customer accessible repo
E-mail to the customer with release notes and info about new version.
lets agree on a structure of this email and what info should be contained (mention App version, Helm chart version, link release notes, mention major feature?)
Version that pushed to the customer repo deployed on the demo instance
Other points
helm chart versioning, and changelog is there a mechanism (planned) like the one for the application code.
why is the helm chart separate from the application code
could be changed in the future
would increase transparency
changes to helm chart would be included in changelog
Add Comment