The goal of this page is to create, share and iterate on the Jobs to be Done and their corresponding job stories for the Release Management group. Our goal is to utilize the jobs theory to better understand our buyers' and users' needs.
Utilize JTBD and job stories to:
When I'm ready to deploy a change I want to deploy to production state for customer consumption so I can get adoption of the product released.
|When tracking important deliverables in my project I want to easily create and manage all related information for a software release so I can provide a packaged software, notes, and files for people to use||Researched||Issue|
|When releasing changes to various environments I want to be able to tag versions of code so I can track an incremental build through approvals to become a production version/build.||Researched||Issue|
|When ready to prepare a new version of my software to be released I want to be able to add all available attributes to my package of release content from a single place (whether in the UI or API) so I can bring all data without having to change application context||Heuristic||Issue|
When ensuring teams are coordinated about Releases I want to deploy to production state for customer consumption so I can show the body of work that goes into deploying to production.
|When I am planning deployments or changes to production I want to make sure all my teams are informed and know what changes will be be made when so I can ensure our customers have positive experience with our code/product.||Issue|
|When I am planning deployments or changes to production I want to use a single tool across multiple projects so I can reduce failure points in the devops lifecycle as a switch tools.||Issue|
|When scheduling a future release I want to keep my release private or only to internal team member so I can publish the final version at a later date.||Issue|
When I am looking at changes to a production environment I want to be able to see who made the changes, when and why the changes were made so I can adequately respond to an audit
|When I am requested from an auditor to sample changes to production I want to easily and naturally provide the source of the change so I can adequately respond to an audit||Researched||Issue|
|When a compliance check is run and the compliance team wants to confirm we have records of production I want to be able to minimize the disruption to the internal teams by empowering the compliance team to self-serve these changes without giving access to the source code so I can adequately respond to an audit||Issue|
|When an auditor is asking for proof of separation of duties in my changes to productions I want to be able to show who made the change and who approved the change to production so I can adequately respond to an audit||Issue|
When I am preparing for the auditor I want to be able to confirm we are following compliance standards around MR approvals so I can correct violations prior to an audit request.
When I need to use a secret/token/password I want to use my HashiCorp Vault so I can leverage the tool I am already using for Secrets Management.
|When I need to use a secret/token/password for a pipeline I want to authenticate into HashiCorp Vault, pass the secret to the CI Job and execute the pipeline so I can leverage the tool I am already using for Secrets Management.||Issue|
When I am deploying changes to environments outside of GitLab I want to easily authenticate and pass the appropriate secrets between GitLab and the environment without exposing the secret so I can deploy my changes to production quickly.
|When I am using secrets for pipelines I want to be able to access those secrets easily and from a single place so I can deploy my changes to production quickly.||Issue|
|When I am working with tokens or passwords I want to keep these secret and avoid revealing the values in an audit log or to other developers so I can maintain secrets management best pratices and avoid a breach of data.||Issue|
|When I am enforcing compliance standards for passwords, tokens, and secrets I want to be able to set automated secret rotation so I can avoid disrupting developers workflows and being in breach of compliance.||Issue|
|When I am accesing a system to deploy my change to an environment I want to be able to access the system without leaving my CLI to log in so I can deploy my changes to production quickly.||Issue|
When I am deploying a static site I want to use kubernetes for my cloud native installation so I can leverage auto-devops and other benefits of K8.
|When I have a custom domain or multiple domains I want to be able to redirect the other domains to my custom/main domain so I can optimize SEO rankings and ensure traffic from like domains are tracked.||Issue|
|When I am setting up a static site I want to be able to set up the site with a wildcard DNS so I can avoid setting up a custom domain.||Issue|