Before
Before the automation, a team member would likely read the Jira request, create the application and infrastructure repositories, copy configuration templates, and generate or add the website files manually. They would then edit environment-specific settings, update CI configuration, remove template files, wait for processing, and return repository or website links in Jira.
How it works
- The flow receives the Jira request, retrieves the issue, extracts the deployment details, and confirms in Jira that processing has started.
- It branches on public or private website type, creates the application and infrastructure repositories, generates the homepage, and commits the initial website content.
- It loops through the requested environments to create and customize configuration files, activates the relevant development or production CI settings, and posts progress and URL references back to Jira.
Workflow details
- Request intake: The workflow starts from a Jira deployment request, retrieves the issue details, and extracts the application name, website type, homepage content, requested environments, and account information. It immediately adds a Jira comment confirming that the workflow has started and that the ticket will be updated during processing.
- Repository provisioning: Based on whether the requested website is public or private, the workflow creates an application repository and a supporting infrastructure repository with the appropriate visibility settings. It then records that repository creation has been initiated in the Jira issue.
- Website generation: An AI step creates an HTML document from the homepage information supplied in the request. The generated content is committed to the application repository as the website entry page, providing the repository with its initial static website content.
- Environment configuration: For each requested environment, the workflow retrieves the relevant configuration template, processes up to four environment files, replaces application, environment, account, bucket, and deployment-state placeholders where applicable, and creates the resulting files in environment-specific repository folders.
- Pipeline handoff: The workflow updates the application and infrastructure CI configuration according to the requested development and production environments, removes template files when required, waits for the repository and pipeline changes to settle, and adds environment-specific website URL references to the Jira issue.
What changed
Repository creation, website content preparation, environment branching, template replacement, CI configuration, and Jira communication now occur from a single deployment request. The workflow applies the public or private path and development or production settings automatically, while the Jira issue becomes the running record of progress and resulting URL references.
Work removed
Manually reviewing deployment requests, creating two repositories, generating or copying the homepage, copying and editing up to four configuration files per environment, replacing application, account, environment, and deployment-state values, removing template files, updating CI settings, waiting between handoffs, and posting progress or URL comments in Jira.
Expected outcome
A repeatable website setup that removes at least two repository-creation handoffs and several manual file and configuration edits per request; no measured customer time savings are established.
