OutSystems DevOps Model Series: 4-Release Management
During the lifecycle of each Product, new versions of software can be deployed to Production using 2 distinct release processes:
- Product Release
- Has an expected schedule (min. 2 weeks), following-up 1 or more development sprints
- Originated from QA environment
- Includes new features, bug fixing and enhancements based on the Product Owner priorities
- Hotfix Release
- Triggered by urgent maintenance actions in response to critical issues (P1) occurring in PRD
- Originated from PP environment
- Includes corrections to critical issues reported by end-users or identified by Product Ops monitoring activities
Every issued release should have the following attached information for traceability:
- Backlog: user stories and defects
- Manifest: included LifeTime applications (tags)
- Runbook: deployment and configuration guide
All release information can be compiled and managed centrally in third party tools. e.g: JIRA and Confluence
Runbook content can be stored and edited in Confluence (linking from JIRA) while release manifest can be synced automatically to JIRA through a LifeTime plugin.
Spoiler Alert: In this series we will not talk about Jira/Confluence Integrations but this can be our next topic in the future.
This way every Product backlog item can be traced forward to the specific release that implemented it.
It is also important to say that each release should be properly versioned, and for that we can follow the following schema:
Major: Software major version, introducing significant improvements and breaking changes from the previous Major release version
Minor: Software minor version, which may include improvements and non-breaking changes for the corresponding Major release version
Revision: Increments only when a new batch of corrections is included in the same version
With that being said, let talk about roles and activities.
Each role in our Model will have a specific function in a determined time.
As an overview this is the release proccess, with the roles defined:
Let’s break down each of the steps needed to understand a little bit better the responsabilities of each role in each phase and how to do it properly.
Release Inception
Every new release should start with a kick-off meeting to align Product and Factory teams
- Share business context, release scope and identified risks
- Align delivery timeline and book tentative dates
- Applications must follow technical guidance guidelines to ensure consistency and best practices compliance - Regular audits are performed to ensure compliance
- Application architecture should already be defined and sanctioned by the Architecture team
- Infrastructure assessment is performed prior to development starts to evaluate impacts and mitigate risks
Code and Architecture Checkpoint
- Architecture role performs code and architecture reviews on a regular basis
- Scheduled at the end of every Product release cycle (ideally at the end of each sprint to minimize delta)
- Uses code review checklist and supporting tools such as Discovery and Architecture Dashboard - Ensures compliance with internal development best practices and global factory architecture
- Normalizes code deliverables while promoting overall code quality and documentation
- Identifies issues earlier in the delivery pipeline reducing technical debt and maintenance costs
Application Staging — DEV -> QA
- Performed by the SD of the owner Product team with full autonomy (if non-impacting)
- Can occur multiple times during release cycle
- Requires alignment with Product testing plan
- If there are cross-team dependencies, Factory team takes over deployment operation
- Runbook information is compiled during development cycle
- Runbook is validated and fine-tuned by SD before handover to Product Ops
Note: Developers may use Feature Toggle, an open source component available for free download from the Forge, to hide unfinished code or exclude deployment of a feature that is not intended for the current release.
Application Staging — QA -> PP
- After release approval from Product Owner, SD role requests deployment to PP and PRD
- Tentative deployment dates are confirmed
- Factory team is notified and kept in the loop - Runbook is handed over to Product Ops who executes it step-by-step if there are no cross-team dependencies
- Factory team takes over when release impacts other Products or requires Factory intervention (e.g. configurations)
- Whenever deployment fails, Runbook needs to be reviewed and kept up-to-date
Application Staging — PP → PRD
- Executed by Product Ops or Factory team on scheduled date, after successful execution in PP
- Runbook is executed step-by-step replicating the same procedure as in PP
- Factory must be aware of all PRD deployments (even if not executing them) - Release differences between PP and PRD environments must be limited to the minimum timespan for hot fixing purposes
- Technical handover to Product Mnt/Ops is done according to the handover checklist
Testing Strategy
- Unit testing performed by Dev/SD roles in DEV
- Integration testing performed by SD role in DEV or QA (if mocks are used)
- Acceptance/Regression testing performed by testers in QA
— Release is accepted by PO - Deployment plans are validated in PP prior to PRD execution
- Performance/Load testing performed by Factory team in PP with SD support
— Can halt release progression to PRD - Smoke tests performed by Ops role after deploying to PP or PRD
Operational Monitoring:
- Covers infrastructure, platform and application layers
- Uses server-side and client-side metrics collected in real-time
- Product Ops engages in product-specific monitoring, oriented towards assessing business impacts
- Factory Ops focus in platform-wide monitoring activities and global platform health check
- Monitoring should be proactive to identify trends and anticipate problems
- Collected findings to be incorporated into new release cycles
Now that we have a nice release process lets talk about Support.
In our next article of this series we will see how we should handle bugs, especially when they are critical and happens on Production environment that is already being used.
If you want to enhance even more your release cycle management and go for a more automated and advanced CI/CD approach you should read this other article from OutSystems related to Application Lifecycle Management and CI/CD.
Next: 5 — Support
Previous: 3 — Access Control Policy
OutSystems DevOps Series Articles:
Disclaimer: Most of the material was gotten from OutSystems documents
