Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

AWS Logo
Menu

Automated Task Development with Amazon Q and GitHub Actions

Combining the /dev workflow of Amazon Q Developer with your CI/CD pipeline to optimize efficiency in your SDLC!

amazon-qamazon-q-developerdevelopmentawsgithub-actions
Ryan Brown
Published Mar 18, 2025
Comments
1

Automating Feature Development with Amazon Q Developer

Hey everyone! 👋 In my last post on Amazon Q Developer, I showed you how to integrate the CLI with GitHub Actions to automate code reviews. Now, I want to follow up and show you how you can take things further—using Amazon Q Developer with GitHub Issues to help automate feature development.

Understanding the Workflow

A typical software development workflow involves multiple roles working together to refine, prioritize, develop, and release a feature. Here’s a quick breakdown of that process:
  1. End User: Raises an issue describing the need or problem.
  2. Product Owner & Business Analyst: Refine the user request and translate it into clear business requirements.
  3. Technical Lead: Converts business requirements into technical requirements and breaks the task down into smaller pieces.
  4. Scrum Master: Prioritizes tasks and manages scope.
  5. Developer: Implements the feature and writes automated tests.
  6. Tester: Conducts end-user and performance testing.
  7. Product Owner/BA: Signs off on the release and communicates updates to the customer.
  8. Customer: Happy with the delivered feature! 🎉

Where Amazon Q Developer Fits In

With Amazon Q for Business, when configured with the right knowledge bases (or other AI-powered alternatives), much of the requirement analysis process can be automated. This helps refine tickets to meet your team’s Definition of Ready before development even starts.
Once the ticket is ready, Amazon Q Developer (integrated into your IDE) can help developers efficiently implement the feature. However, this doesn’t solve challenges around capacity management, prioritization, and reducing context switching.

Automating Ticket Development with Amazon Q in CI/CD

With the right prompts, running Amazon Q Developer in a CI/CD pipeline can act like an automated ticket assignment system. Since CI/CD pipelines already have a local clone of your repository, triggering the /dev command in the pipeline is equivalent to a developer running it manually on their laptop.

Benefits of this approach:

Reduces bottlenecks by automating ticket execution. Minimizes context switching for developers. Ensures continuous progress on tasks using AI-driven automation.
By integrating Amazon Q Developer in this way, you can take automation one step further, streamlining development workflows and making feature delivery faster and more efficient. 🚀

A Practical Example

Below is a basic feature development workflow I set up using GitHub Actions and Amazon Q Developer CLI, and a video for those who don't like reading

Step By Step Guide

Step 1: Set Up Your Guardrails

Since this setup allows Amazon Q to update and edit files in your repository, you must have proper guardrails in place:
  • Ensure Amazon Q only works on a feature branch (never directly on main).
  • Enable repository protection mechanisms:
    • ✅ No rewriting history
    • ✅ No unauthorized merges into main
    • ✅ Restrict who can push to main
You can limit actions in the prompt, but the best restrictions are enforced at the repository level.

Step 2: Building the Prompt

Amazon Q Developer has a 4,000-character limit for chat prompts. Passing the full ticket content directly can lead to mixed results or outright failures. I found that writing the issue content to a local file and having Amazon Q read from it worked much better.

Example Prompt for Building a Static Website

If your local documentation (README.md, CONTRIBUTING.md, etc.) is up to date, you can provide Q with additional context from those files as well. Q does well with Markdown and AsciiDoc files, but not PDFs (yet).

Step 3: Grabbing the Ticket Details

Now that we have our prompt, we need to generate the issue_content.txt file.
In GitHub Actions, you can do this using:
  • The GitHub CLI
  • The built-in trigger variable: ${{ github.event.issue.body }}
This method is GitHub-specific, but I'm sure GitLab and Bitbucket have similar CLI/API options.

Example: Generating issue_content.txt

Step 4: Previewing the Changes by Automating Pull Requests

For me, the quickest way to review changes made by Amazon Q is through the diff feature in a pull request. This allows me to add comments and suggestions easily.
But let’s be real—one of my pet peeves is people using the same commit message over and over again (chore: fix)… and, yes, I’m guilty of it too. 😅
So, I figured—why not have Amazon Q summarize what it did?
  • Pull Request Notes – A clear summary of what was changed.
  • Commit Message – A meaningful description of the work done.
Using GitHub Actions, we can create a pull request via the CLI. Since the CLI errors out if the PR already exists, I added a simple bash check to prevent failures.
Note: Amazon Q, being an LLM, won’t always follow the prompt exactly, especially if overloaded with too much issue content or a huge workspace. So, I also added fallback PR notes and a default commit message just in case.

Example: Creating a Pull Request via GitHub CLI

Step 5: Putting It All Together

Here’s the full GitHub Actions pipeline I built,
Additional things I've implemented as part of this pipeline:
  • Triggering on a Label: I used the label "ready-for-ai-development" as a trigger. This prevents Amazon Q from starting development until the task is fully defined.
  • Label Management: Labels help track the AI’s progress and potentially indicate failures if something goes wrong.
  • Pull request commenting, always handy.

The end!

This setup has been a fun experiment, and while it's still a work in progress, it's exciting to see how AI can help streamline feature development. And how it could look like in a production setting!
Would love to hear your thoughts! Have you tried something similar with Amazon Q or another AI tool? Let me know in the comments! 🚀
 
Comments
1

1 Comment