build release process in jira-software cloud

[Gomez, Daniel]

Currently we package a build through our release planning process, and then put it to testing. Due to timeline considerations we get pressed to push the build forward even though all tickets are not fully tested. We are not in production yet so we had a little leniency, and low risk, up until now. We need a way to uncouple the release package if a ticket or tickets don’t pass test, and push the rest of the tickets forward. There were talks of release candidates, putting changes into a master branch and controlling pull requests, and separating resources between development and release, in order to pass audit. Even with a way to pull out tickets that don’t make the test, regression testing on the final package would still need to be considered in the timing, due to the interconnections of code and fixes. I'm looking for a better approach in handling this situation.

[Gomez, Daniel]

. 

now that we have skynet gpt, here's a possible outcome that might work. Criticism is more than welcome here:

It sounds like you're facing challenges with your current release process, particularly in managing the testing and release of builds when not all tickets are fully tested. Here are some suggestions for improving your approach:

1. **Feature Branching and Pull Requests:**
- Instead of merging all changes into a single branch for testing, consider using feature branches for each ticket or set of related tickets.
- Developers can work on their features in isolation, and once they are ready, they can create pull requests to merge their changes into a development or integration branch.
- Pull requests should include automated tests to ensure that the changes don't break existing functionality.

2. **Continuous Integration (CI) and Continuous Deployment (CD):**
- Implement CI/CD pipelines to automate the build, test, and deployment processes.
- CI pipelines can run automated tests for each feature branch, providing early feedback on whether a ticket passes tests or not.
- CD pipelines can automatically deploy successful builds to a staging environment for further testing and validation.

3. **Release Candidates:**
- Instead of pushing incomplete builds to testing, consider creating release candidates from stable feature branches.
- Release candidates are builds that are considered potential candidates for release pending final testing and validation.

4. **Rolling Releases:**
- Adopt a rolling release strategy where features are released incrementally as they are ready, rather than bundling all changes into a single release.
- This allows you to push forward with the release of tested features while holding back features that are not ready.

5. **Regression Testing:**
- Develop comprehensive regression test suites that cover critical functionality and areas affected by recent changes.
- Include automated regression tests in your CI/CD pipelines to ensure that new changes don't introduce regressions.

6. **Release Management:**
- Establish clear criteria for what constitutes a release-ready build.
- Use release branches to prepare and stabilize builds for release, allowing for final testing and validation before deployment.

7. **Communication and Collaboration:**
- Improve communication and collaboration between development, testing, and release teams to ensure everyone is aligned on the status of tickets and builds.

8. **Agile Practices:**
- Consider adopting agile practices such as Scrum or Kanban to improve transparency, flexibility, and adaptability in your release process.

By implementing these strategies, you can improve the flexibility and reliability of your release process, allowing you to push forward with tested features while managing and addressing any issues with incomplete or untested tickets separately.