The goal of this page is to document, share and iterate on the Jobs to be Done (JTBD) and their corresponding job statements for the Pipeline Authoring group. Using JTBD framework we intend to arrive at the more specific problems to be solved in relation to Pipeline authoring workflows.
Utilize JTBD and job statements to:
Once I have a stable development and operations organization, I want to author a CI pipeline so others in my team can leverage CI to increase the efficiency of their tasks.
|When authoring a pipeline I would like to know what are the available keywords and their descriptions so I can set-up my pipeline in the most efficient way.||Researched||Issue|
|When editing my CI/CD configuration, I want to easily access all CI/CD files from one place so I can efficiently configure my CI/CD configuration without a lot of context switching.||Researched||Issue|
Once I have a stable development and operations organization, I want to make the teams in my organization feel comfortable using CI/CD so we can increase the efficiency of our tasks.
|When implementing CI/CD practices across the organization, I want to ensure consistency and standardization of CI/CD workflows to ensure compliance and to ease and increase CI/CD adoption across my teams.||Researched||Issue|
|When implementing CI/CD practices across teams in my organization I want to easily communicate the guidelines for standard practices for automation to them so they can focus on shipping quality products.||Researched||Issue|
|When setting up a new project I want to effortlessly set up reliable, efficient and compliant automated tasks so I can quickly move on to writing high quality code.||Researched||Issue|
When feeding in values to a development environment through variables, I want to have stricter control over the variables so they could not be used by other environments and result in a security or performance concern.
When secrets are referenced in automated tests and processes, I want them to be handled securely, so I can share my credentials without risk of being exposed.
When architecting pipeline configuration, I want to be able to define the variable so that it is dynamically inherited across all hierarchies of a repository and upstream or downstream a pipeline in order to perform complex operations without scripting those tasks to save time across repositories.