Take Action: Go Fast with GitHub at Live360 Orlando

Last week, I had the opportunity to deliver a Visual Studio Live! session called Take Action: Go Fast with GitHub.

The title was intentionally a little direct. It was not “Think About Actions.” It was not “Plan to Automate Eventually.” It was Take Action. That was the point of the session.

Most teams I talk to already know they should be automating more. They know manual builds are fragile. They know deployments should be repeatable. They know pull requests should do more than collect comments. They know security should show up earlier in the process. And now, they know AI is changing the way developers work.

The hard part is turning all of that into a practical software delivery workflow that teams can actually use. That is where GitHub becomes interesting.

Going fast is not the same as rushing

When I say “go fast,” I do not mean skipping the important parts. I do not mean deploying without tests. I do not mean ignoring security. I do not mean letting every developer invent a different delivery process. Going fast means reducing unnecessary friction between idea and production. It means making the path easier to understand, easier to repeat, and easier to trust.

That is why GitHub Actions was the center of the session. Actions gives teams a way to bring automation directly into the place where the work already happens: the repository. The workflow lives with the code. Changes to the workflow can be reviewed. Build and deployment logic becomes visible to the team. Pull requests can trigger validation. Deployments can be tied to environments. Security checks can become part of the development process instead of an afterthought. That is not just CI/CD. That is developer experience.

From repo to cloud

A big part of the session focused on deploying an application to Azure using GitHub Actions. That “repo to cloud” path matters because it is where a lot of teams still experience friction. They can write the app. They can run it locally. But getting it built, validated, deployed, and governed consistently is where things often get messy.

GitHub Actions helps create a cleaner path. A basic workflow can build the application, run tests, authenticate to Azure, and deploy to the right target environment. From there, teams can add environment approvals, secret management, infrastructure as code, security scanning, and release controls. The point is not that every workflow needs to be complicated. The point is that every team deserves a repeatable path. Even a simple pipeline is a big improvement over “it works on my machine.”

Pull requests are where the work comes together

One of the themes I keep coming back to is that pull requests are more than a merge button. A good pull request is a collaboration point. It is where code, context, review, automation, policy, and increasingly AI all come together. When a pull request opens, GitHub can run builds, tests, security checks, and deployment previews. Reviewers can discuss the change in context. Copilot can help summarize, explain, or reason through parts of the work. Advanced Security can surface risks before they become production problems. That is a very different workflow from treating CI/CD as something that happens off to the side. The closer automation is to the developer workflow, the more useful it becomes.

Copilot makes the workflow more approachable

GitHub Actions is powerful, but YAML can still be intimidating. That is one of the reasons Copilot matters in this conversation. Copilot can help developers get started with workflows, explain what an existing workflow is doing, troubleshoot errors, generate test scaffolding, and understand deployment steps. It can reduce the blank-page problem that often slows teams down when they are trying to automate something for the first time. But the important part is this: Copilot should not be treated as a replacement for understanding.

It is a learning accelerator. A developer still needs to know what the workflow is supposed to accomplish. A team still needs standards. A reviewer still needs to understand what is being changed. The organization still needs governance. Used well, Copilot helps teams learn and move faster inside good engineering practices. Used poorly, it can generate more things people do not understand. The difference is the operating model around it.

Security belongs in the workflow

Another important part of the session was GitHub Advanced Security. Security should not be a surprise at the end of the delivery process. If a team only finds out about secrets, vulnerable dependencies, or code scanning issues after the work is already done, they are going to move slower and create more risk. The better approach is to bring security into the developer workflow.

That means surfacing issues where developers already work. It means making security findings visible in the pull request. It means helping developers fix problems while the context is still fresh. It means shifting security from a late-stage gate to an integrated part of software delivery. That is how teams move quickly and safely. Not by ignoring risk. By finding it earlier.

GitHub as the delivery platform

The more I work with teams on GitHub, the more I think the platform story matters. Actions is not just a CI/CD tool. Copilot is not just autocomplete. Advanced Security is not just a scanner. Pull requests are not just code review. Each piece is useful on its own, but the real value shows up when they work together. GitHub becomes the place where teams collaborate, automate, secure, deploy, and improve the way they build software. That is why I talk about GitHub as a platform for modern software delivery, not just a place where code lives. The session was a practical version of that message.

  • Start with the repo.
  • Add automation.
  • Deploy to Azure.
  • Use pull requests as the collaboration point.
  • Bring Copilot into the workflow.
  • Bring security into the workflow.
  • Make the path from idea to production faster, safer, and easier to understand.

The takeaway

If there is one idea I hope people took away from the session, it is this: You do not need to wait for a massive transformation program to improve software delivery.

You can start with one repository. One workflow. One pull request process. One deployment path. One security check. One better developer experience.

That is how teams build momentum.

GitHub gives you the pieces. Actions gives you the automation. Azure gives you the cloud platform. Copilot helps make the work more approachable. Advanced Security helps teams move safely. The opportunity is to connect those pieces into a workflow your team can trust. That is what “go fast with GitHub” means to me.

Not rushing. Not skipping steps. Taking action.

Scroll to Top