Brent Laster

Congratulations to all the winners! And thank you to Code Ranch and those who helped with this promotion.  I appreciated and enjoyed getting to answer the questions.

Hi - thanks for the question.  Yes the book covers sample workflows and more detailed examples that can be used for CI/CD integration. CI/CD is one of the main uses of Actions. There are starter workflows that you can pick from to get up and running quickly.  Just click on the "Actions" tab in your repository and pick from the CI/CD category of starter workflows.  There are also some examples in the last chapter of converting from popular CI/CD applications like Jenkins, Travis CI, Azure DevOps and more.  So it's very easy to get going in my opinion.

Hi Greg - thanks for the question.

In my 25+ years of experience with inner and outer loops, I can say that I'm more of a fan of using the pull request model as the ultimate gate for changes. I have certainly used pre-commit git hooks (which are hard to enforce across dev teams) and tools like Gerrit (which "capture" the code between the commit and push and allow you to run checks there).

While I would not every attempt to dissuade anyone from having good testing/pre-commit/pre-flight checks, I do think it is important to use a pull request type of model to gate changes.  With GitHub Actions, you can set up required workflows (equivalent of pipeline scripts) to do things like security scans, trial builds, and run tests at multiple levels when a pull request is made. That gives you both powerful "pre-checks" before final merge and a standardized way of enforcing the checks across all changes - as opposed to having to rely on local commit checks only.  As an example, you can look at the list of workflows that are used to validate changes for the "checkout action" at https://github.com/actions/checkout/actions

As well, I've found that I am doing more and more of my changes in the GitHub browser interface or things like GitHub Codespaces which don't really require the same local clone/commit processes.  In fact, if you're viewing a file in GitHub, and click the "." key or change the URL to start with "github.dev" rather than "github.com" you get a browser-based version of VS Code.  In those situations, pre-commit hooks/checks don't really apply so that's another reason I'm a fan of utilizing the GitHub Actions workflows triggered on pull requests as the gating checks.

Hope this helps.

Thanks for the question Simon. The overall focus of the book was on helping people understand first what X is and then how to put it into use. I did try to make sure I noted any pitfalls I encountered along the way. In fact, I reported a couple of bugs to the GitHub Actions teams as I encountered them. In terms of recommendations, I included ones I came across, and, in many instances, I asked my contacts at GitHub for the best practices and shared those back. Hope this was helpful.

Hi Carl, thanks for the question. There's an analogy I like to use for CI/CD and DevOps for producing software as being like an assembly line. That is, like an assembly line produces mass goods in a fast, automated and reproducible manner (like a car manufacturing plant) a software delivery pipeline generates releases from source code in a fast, automated, and reproducible manner.

The CI/CD pipeline is like the assembly line.
The process that kicks off the assembly line by feeding in raw materials is referred to as Continuous Integration. In its simplest form this means that a process or application is either watching for updates in a source management system or is notified via a hook or such that content has been updated in the source management system. The change is pulled and put into the pipeline as base materials are added on to the start of an assembly line.

In an assembly line, the base materials pass along various stations where they can be modified or added to, etc. as steps towards the finished product.

In the software pipeline, the changed source code passes through stations (stages) where it is automatically built into binaries, tested, packaged with other modules, etc.  That overall process is called Continuous Delivery. Given changed input, it is always ready to run and deliver the end result without manual intervention.

As the product passes along the assembly line, it is transformed more and gets more complex. In a similar way, the software gets more complex as it goes through the pipeline from source to module to being combined with other modules, etc.

As an assembly line has quality control checkpoints at various places along the line, so CI/CD has quality control in the form of different automated testing  at different points - unit testing, functional testing, integration testing, etc. This is "continuous testing."
The overall design for how this is done is called Continuous Delivery.

Once completed, the product from the assembly line can be automatically shipped and delivered or it could be stored for some period of time.

Likewise, the software produced from the CI/CD pipeline can be automatically deployed (if we choose) or it can be set aside and a manual decision made of which version to deploy and when.

I could go on, but I've probably labored this analogy enough. Done correctly, a CI/CD pipeline minimizes barriers, handoffs, and confusion among development teams and operational teams—goals that are part of the DevOps approach to software delivery.

GitHub Actions is an automation platform that can be used (among other uses) to implement CI/CD easily for changes that happen in GitHub repositories.  

Hope this helps.  

Hi Sean, thanks for the question. I focused in that chapter on the systems that the GitHub Actions team had included some automation for via the migration tool discussed in the chapter.  I personally have very little experience with BitBucket and no experience with BitBucket pipelines unfortunately.  With that said, the overall general approach outlined in that last chapter should help in terms of preparation and the stages of source, CI, users, etc.

For the actual conversion, I would suggest looking at basic structures/processes (such as calling a shell command or checking out code) and then implementing small jobs in a GitHub Actions workflow to do that one targeted piece. Then you can start to build up from there to the larger pipelines. If you need to do fairly straightforward migrations for sections of pipelines, you could write custom scripts to search for the BitBucket pipelines and create the new GitHub Action pieces. I would suggest this could be a time-consuming process if you're just working on it yourself for a group effort.  If that's the case, I'd suggest getting the team some training in GitHub Actions and then breaking up the typical functions of your pipeline so each team member works on implementing a corresponding job in a GHA workflow and then all can benefit from the shared knowledge. Hope this helps.

Hi Sean, thanks for the question. For most of the stuff, I'm certain if you dig far enough, you can find the details in the documentation. And, in fact, there are key places (such as tables for costs, etc.) where I specifically encourage readers to consult the documentation for the latest information as those kinds of things are subject to change. What (I hope) the book provides is an ordered presentation of the material in a sequence that helps readers understand not just the "what to do" but also why you would (or wouldn't) do something. That kind of personal experience is something I've tried to build in.  For example, there are cases in the book where I cite what doesn't work or work as you might expect (at the time of writing). There are other places where I try to explain or summarize some complex topics that I don't think are covered as well in the documentation. And there are places where I've injected my own experience with using Actions and workflows into the mix. In short, the tech that works and other examples of that are covered in the documentation, but the first-hand perspective, personal experience, advice about what doesn't work or doesn't work as expected, and ordered presentation so people can jump in at whatever level of knowledge they have about actions are things I personally think are better covered in the book. Hope this helps.

Hi Greg, thanks for the question. I honestly haven't really had a need to implement a public action except for demonstration purposes. In my experience, using "reusable workflows" typically meets the needs better for code reuse if I'm just trying to isolate/not repeat a section of code. Reusable workflows require the ability to express the logic in a GitHub Actions workflow versus you having more freedom to code in some other form like Javascript for the action. So, creating a new action would be more suitable where I needed to implement the functionality with Javascript, Typescript, or a specialized environment like a Docker image. A public action is also a good choice if you're intending to provide functionality that you want to be more publicly accessible and consumable - similar to the notion of a Jenkins plugin. For example, many companies/products provide public actions that you can pull into your workflows to get the functionality of their products.  Public actions also allow for "branding" with icons, etc.  Hope this helps.

Hi Joseph, sorry but I'm not clear on the question.  Please feel free to add more information.  The title mentions Visualization - GitHub is primarily a browser-based interface similar to GitLab (since you mentioned you've played with that). Actions has a browser-based interface built into GitHub through the "Actions" tab in the repository view that shows past runs, a job graph with color-coding for success/failure etc. - similar to the type of information presented in the Stage View of Jenkins if you're familiar with that.

You also mentioned IDE virtualization. Did you mean visualization? GitHub integrates well with multiple IDEs - especially ones like VS Code.  There is also GitHub Codespaces which provide a virtual dev environment - that's worth checking out if you're interested in virtual dev environments.  For most repositories you can find it under a tab when you select the "Code" version.

Hi Gustavo, thanks for the question. So GitHub Actions is an automation platform/framework integrated with GitHub. If you store your Java code in a GitHub repository, then you could use Actions to automatically do items like CI/CD, deployment, security scanning and other automation with it through GitHub - similar to what you might have used Jenkins for in other circumstances. Workflows in Actions are like scripts or programs or Jenkinsfiles if you know Jenkins.

If you have a GitHub repository and go to and add "actions/new?category=none&query=java" onto the end of the repository URL, you can see the various starter workflows around Java (though you'll probably also see ones for Javascript as well).

Hi everyone,

I'm Brent Laster, a global trainer, DevOps director, and book author.  I love writing and training on new technologies and will be promoting my latest book -  Learning GitHub Actions in September.  Hope we have a chance to connect and looking forward to engaging around the book and GitHub Actions!

Brent