Welcome to the deep dive. We're jumping straight into what it takes to build and deliver software better, not just you know, the coding itself, but the whole process getting it out there efficiently, securely, all.
Of that exactly. And we've got a really rich set of information we're drawing from mostly this comprehensive guide. It looks at everything from managing projects right inside GitHub to some pretty advanced security practices. It even digs into how team structures well, how they influence the software itself, and to.
Give us a wider perspective, we're also pulling in some industry reports, articles, that kind of thing. They provide some real world context, some data to back things up. Yeah.
Absolutely so for you listening, our goal here is to cut through the noise, really pull out the key insights on how to well level up your software delivery.
Whether you're writing code, managing.
A team, or maybe just curious about how modern software development actually works. We're aiming to give you that core knowledge without burying you in details.
Okay, so the question, the central mission for today is what are the most effective practices, the best tools that software teams can leverage right now to speed things up?
Speed up development, speed up delivery.
But and this is key while keeping quality and security absolutely top priorities.
Exactly, And the guide we're using really kicks off with this idea, this fundamental point. Software development is a team sport totally and right at the heart of that teamwork, you find the poll request.
Ah, the poll request, So when a developer wants to propose changes, that's the mechanism, that's it. The guide walks through it, creating them draft prs for work in progress code owners. Code owners, yeah, saying who needs to look at what? And required reviews. Obviously can't merge without those checks.
We won't get bogged down in every single click. But it sets the stage for collaboration.
But what's really interesting is the emphasis on making those code reviews effective.
Yes, the guide really hammers this home well. Structured commits are key. Each commit should tackle one single logical change, and the commit message it needs to be clear what did you do and why did you do?
It makes total sense trying to review a giant commit with mixed up changes and a vague message like fixed stuff forget.
It impossible, right, And it specifically warns against mixing, refactoring, you know, just cleaning up code with adding new business logic in the same commit Oh yeah, that.
Just muddies the waters for the reviewer completely.
Keep them separate. Reviewers can focus on the actual functional change, understand its impacts.
Makes the whole process way more efficient, and you're more likely to catch issues early.
Exactly, it's just good practice.
Okay, let's think about how teams actually work today. So often they're spread out right, different places, different time zones.
Distributed teams are becoming.
The norm, and the Guide spends some time on this shift towards asynchronous communication.
It's interesting if you look at the history communication shifts used to take generations. Now it feels like every few years, smartphones, the Internet, it's pushed us towards preferring ACNC stuff quick messages, emails where you don't always expect an instant reply.
I remember when waiting a day for an email reply was totally normal. Now it's like, if you don't hear back in.
An hour, you start wondering, right, But for distributed teams, that expectation of instant replies that can actually slow things.
Down oddly enough, become a bottle lick.
Hey, exactly, And that's where ACNC workflows really shine. The guide highlights a few best practices here. One big one prefer chat platforms over email for work discussions. Why is that keeps the conversation history all in one place. If someone's offline, the info isn't just stuck in their personal inbox, anyone can catch up.
Yeah, email threads could become absolute monsters. The other really interesting suggestion was making most meetings optional.
Right, this is a big one. It forces you to ask is this meeting really necessary for everyone invited? The thinking is if people don't see clear value, they should feel okay skipping it.
Which puts the pressure on the meeting organizer to make it worthwhile.
Be focused, prepared, know that people are choosing to spend their time there.
Now, obviously some meetings you need everyone for team building, big company updates.
Of course, the guide acknowledges that it's not about eliminating meetings, but making them more intentional.
Okay, so keeping all this work organized tracking it. The guide talks quite a bit about getub projects as a platform for that.
Yeah, it's presented as really adaptable. You can add all sorts of work items, tasks, bugs, features.
Whatever, and attach metadata.
Exactly status, priority, who's assigned all that stuff? And it highlights two main views, the table.
View good for data entry sorting right, and the board.
View that visual canban style, drag and drop thing.
Lots of teams love that visual overview is huge for seeing where things stand, spotting blockers.
Quickly, and the guide mentions the beta version of projects is where things are headed even more flexible, easier to to share configurations across teams. That's the future direction and a core part of planning and tracking. In Geithub issues Right GitHub issues, the guide explains how they're used for well everything, tracking tasks, suggesting features, logging bugs, and they're collaborative, totally full history linked directly to commits, pull requests, even other related issues.
So issues become the central hub for anything related to a specific piece of work or problem pretty much.
And there are some neat features like creating hierarchies. Breaking down big tasks into smaller subtasks makes things more manageable and.
The filtering and sorting powerful.
The guide points out that every filter you apply just adds text to the search bar, so it's super transparent. You can quickly see status labels, linked prs.
Everything and for consistency especially with lots of different types of issues flying around. The guide really pushes issue templates.
Oh, this is smart. You can create templates using markdown for free form texts, or yammel or yamal for structured forms, text boxes, drop downs, check boxes. You can even make fields required.
Ensure as you get all the essential info.
Upfront, right standardizes things mix processing new issues much faster.
Okay, let's zoom out a bit talk about the influence of open source and this related idea of inner source. The guide as a whole chapter on this.
Yeah, and it gives some interesting historical context the free software movement. How open source became the preferred term in the late nineties, Eric.
Raymond, Bruce Parrins the Open Source Initiative exactly.
Linus Torvalds, creators of Pearl Python, getting those key figures on board early was huge.
It's amazing how much foundational tech is open source now. But the guide makes a great point. It's not just about using open source code, No, it's.
About learning from how those successful open source projects work, the collaboration models.
And applying those principles inside your own company.
That's inner source. Yeah, it can really boost collaboration between internal teams help share knowledge, but.
The guide is bound, so it warns about risks too, right, license.
Compliance big one, and understanding that if an open source component has a bug or vulnerability, well that's now potentially your problem too. Managing dependencies is.
Critical, which leads to that strategic decision. Yeah, build it yourself insourcing or use external stuff outsourcing?
Yeah, the guide suggests you really need to think is this software core to our business? Does it give us a competitive edge? If it is generally? Build it internally, maybe some cosourcing, but own that expertise long.
Term makes sense. You don't outsource your secret sauce.
But for non core stuff, outsourcing or leveraging good open source solutions can be smarter, less risk than being the only customer for something niche, potentially better quality from a wider community.
And connecting to all. This is getub sponsors.
Right, a direct way for companies, even individuals to financially support the maintainers of open source projects they depend.
On giving back helping keep those projects sustainable. Okay, let's pivot to a core DevOps practice automation with GitHub actions. Big section on this.
Yeah, this is where we really start talking about accelerating the delivery pipeline. The guide breaks down the basics. Workflows are your automated processes.
Pipelines are the stages.
Actions are the individual steps, and it introduces YAML, the language you use to define.
All this YAML. That indentation can look a bit scary at first.
You can, but the guide explains the basics pretty well, comments, data types, how lists and dictionaries work. It helps get you started. Then it moves into defining a workflow, giving it a name, setting up the triggers.
The triggers the events that kick off the workflow.
Exactly and they're super flexible. Run on a push to a specific branch like main or release branches, or when a pull request is opened, or as signed or labeled, even on a schedule. Lots of control over when things run automatically.
Now automation, especially deployments, you need to handle secrets securely. Yeah, API keys.
Path absolutely critical. The guide emphasizes this. GitHub provides secure storage for secrets at the repository level ORG level, even for specific deployment environments.
Encrypted never shown in logs.
Right at the org level, you can control which repos can access which secrets. For environment secrets, you can even require manual approval before a workflow uses them extra security.
Layer, and you can manage secrets via the CLI too for scripting m HM.
The guide mentions that, and it clearly shows how to use secrets in your workflow, using the secrets context, passing them as inputs to actions, or as environment variables.
What about building your own actions, not just using ones from the marketplace.
The guide covers that too. Walk through an example. Define an action dot AML file describing inputs, outputs, how it runs, and.
An entry point dot S script with the actual commands exactly.
You define what inputs your action needs, what outputs it produces. It's pretty powerful and.
If you build something cool, you can share it on the marketplace.
Yep, publish it, let others use it. Builds that whole ecosystem of reusable automation components.
Okay, last bit on actions. Where do these workflows actually run? Hosted versus self hosted runners?
Right? GitHub hosted runners are vms managed by GitHub, Linux, Windows, macohsts. Each job runs in a fresh, isolated environment.
Isolation sounds good for security and you get admin privileges.
That's surprising, it is, But the downside can be build times. If you need lots of tools installed each run and cost.
How does cost work?
Free for public repos Mostly private repos get an allocation of minutes and storage with your plan go over you might.
Pay extra and self hosted.
You provide the infrastructure. You manage. The machines might be necessary for specific network rules like ip alo lists. More control, but more management overhead.
Okay. Automated builds are sorted. Now managing the packages. The dependencies getub packages.
This is about managing dependencies in a structured way. The guide mentions popular register NPM for JavaScript, Docker for containers, nugit for dot net, and.
You can integrate these with GitHub actions roamlessly.
You can automate the whole release process. Build succeeds dot BA back publish to the registry.
And using semantic versioning major minor patches. Yeah.
The guide stresses using simber and automating the versioning with actions. Trigger a workflow on a new GitHub release. It automatically bumps the version using tools like NPM version or git version, then publishes the package. Streamlines everything fewer errors.
For container images, it mentions the git ub container registry, GHCR dot io.
Right images can be owned by ords or users, fine grained access.
Control, and again automate it with actions.
Build the docker image, log in securely using the jit hub token, push the image. It makes sharing code as containers or versioned packages much much smoother solves a lot of release headaches.
Okay, codes packaged now, deployment infrastructure as code iac and automation.
There super fundamental and modern DevOps IC means managing your infrastructure servers, networks, databases using code, not manual clicks. The guide lists the big tools Terraform, polumy, Ancable, chef Puppet.
It makes a point though, just because a tool supports multiple clouds doesn't mean your exact config works everywhere without changes. Right correct.
You'll still need some cloud specific bits, but the core benefit is consistency, repeatability in managing infrastructure.
How do team structure deployment responsibility?
The guide mentions a few models centralized where an OPS team handles everything, Decentralized where feature teams deploy their own services, more and template.
It, where a central team provides templates.
Exactly feature teams use and customize them. Good balance between consistency and flexibility.
And reusable workflows and actions help here too.
Definitely enhance consistency, efficiency, and.
Deployment and measuring success. Back to the four keys.
Yep, the Dora metrics deployment frequency, lead time for changes, meantime to restore or change fail rate if you're auto deploying. The guide says, move beyond surveys track these real world metrics.
Okay, shifting gears, managing feature rollouts, feature flags or toggles.
Super powerful technique. Deploy new code to production, but keep the feature turned.
Off initially, then rolled out gradually.
Yeah. The guide outlines a typical life cycle ideation, internal testing, alpha, beta with small external groups, then maybe a preview release eventually default for everyone.
Advantages seem clear. Merge code more often, zero downtime deployments by hiding unfinished stuff.
Much more control over the rollout. But beware feature flag.
Hell ah, yes, too many flags. Nobody knows what they.
Do exactly, so best practices track metrics on flag usage, have central management with clear ownership, document dependencies between flags, keep it tidy.
And flags aren't just for releases, but for experiments too. Ab testing.
Absolutely formulate a hypothesis this new feature will improve conversion by x percent. Use a flag to show it to say ten percent of users compare their behavior to the control group ninety percent.
Gather data, validate or invalidate your idea objective measurement exactly.
The guide even has an example with a simplified registration dialogue Test.
Okay, different topic. Managing code branches trunk based development, faster velocity.
That's the claim The core idea very few long lived branches. Ideally age is one main trunk feature branches, keep them super short lived, merge back daily.
Ideally it's more model than a strict workflow.
Right adopted by many high performing teams. The guide talks about GitHub flow and variations like myflow as examples.
What's the issue with pure GitHub flow? Sometimes deploying every pr straight.
To prod can become a bottleneck, So a pragmatic adaptation validate prs in a test environment but only deploy to prod after merging to the trunk makes sense.
And with short branches frequent merges, code integration is key, urging, rebasing.
Dealing with conflicts. The guide covers techniques also handling hot fixes for old releases using cherry pick.
It even has that cool get alias example amstart.
Yeah in their miflow strategy automates creating a branch, committing changes, pushing, creating a draft pr nice little workflow helper.
Now ensuring quality in this fast pace. Yeah, shift left testing testing earlier.
Crucial, The guide argues, manual testing just doesn't scale anymore. You need robust, automated tests, owned and maintained by the dev team itself.
Why own by devs?
If developers test their own code, they tend to write more testable code to begin with.
Uh makes sense, So shift left principles.
Test at the lowest level possible. Unit tests first, right tests once run everywhere. Treat test code like production code. Keep it clean and the core you code it, you test it. Develop a responsibility.
It mentions a testing manifesto QA roll evolving.
Yeah, QA isn't just finding bugs at the end. It's about building quality in throughout the process. And then it dives in to TDD test driven development.
Write the test before the code right the.
Red green refactor cycle. Write a failing test, read write the minimum code to make it past green, then clean up the code. Refactor leads to better design, less debugging later.
Then manage the whole test portfolio, unit integration end to end.
Know the difference, use them appropriately The guide lays out their characteristics and.
Then things like fault injection, chaos engineering, proactively breaking stuff.
Sounds scary, but it's about testing resilience. Introduce failures in production controlled to see how a system handles it. Verify your safeguard's work builds really.
Robust systems igh stakes, and finally, test management in GitHub tools for tracking results.
Yeah, integrating test results into the workflow.
Okay. Another shift left security devsekops. Integrating security throughout not an afterthought.
Starts with the assumer reach mindset and zero trust principles. Don't assume your internal network is safe, assume a breach could happen anywhere. Focus shifts to detection, response.
Recovery, and prepping for that with attack simulations Red Team, Blue Tank.
Exactly, Red Team attacks simulated, ethical, Blue Team defends, identify weaknesses, raise awareness, train response teams. The guide has ground rules for doing this safely and productively.
Common attacks to watch for.
Phishing, unprotected resources left open, exploiting compromised machines, spear phishing too. The targeted kind and.
Gidthub code spaces is a more secure dev environment.
Yeah, hosting the whole workspace in the cloud reduces the attack surface on local machines.
Makes sense now. Securing the code itself, getub features.
For this DependaBot is huge automatically checks dependencies for vulnerabilities, creates prs with updates, supports tons of ecosystems, set it daily, weekly, monthly, keeps things patched.
Huge timesaver prevents known vulns creeping in and secret scanning.
YEP scans public, repos and private if you have advanced security for accidentally committed secrets, API keys, tokens, oops.
And code QL for deeper static analysis.
Right set it up in actions scans code for security issues, quality problems without running it. Results show up right in the pull request.
That PR integration is gold, catch issues before merging.
Totally, and you can write custom co QL queries for specific patterns you care about.
Okay, beyond the code securing deployments, container scanning, infrastructure scanning, you need to check those two.
The guide mentions tools like anchor Claire for containers have infrastructure policies. Audit configus regularly.
And automated infrachanges with ic managed via.
PRS provides that audit trail control. The guide brings up the solar winds attack as a reminder.
Supply chain security critical.
Which leads to things like s BOM software bill of materials, what's in your software?
Commit signing, verifying the author code.
Signing, verifying the release integrity? All important pieces.
What about active testing?
Dynamic application security testing? Test the running application? O wasp z app is a popular open source.
Tool for this and generally harden the whole release pipeline, secure runners, lease privilege monitoring.
The whole nine yards. Security needs to be baked in everywhere, and.
The guide circles back to E shaped team members.
Yeah, people with broad experience, deep expertise, curiosity for exploration and strong execution skills need that mix for high collaboration across all these areas.
So how do we measure if all this is working? Metrics that matter engineering velocity, developer productivity.
The guide starts with the why why accelerate companies life spans are shrinking. Digital capabilities are crucial for survival. IT mentions the McKinsey Developer Velocity Index.
DVII HIDVII companies outperform significantly.
Yes, So how to measure back to the four keys deployment frequency, lead time for changes, MTTR, change fail rate, use surveys initially if you have to, but aim for direct measure.
But productivity is broader than just those four, much broader.
The guide introduces the space framework satisfaction and well being, performance, activity, communication and collaboration, efficiency and flow, need a balanced view.
And OKRs objectives and key.
Results to align engineering work with business goals, track progress, prioritize effectively.
The guide then quickly revisits some earlier topics in light of metrics.
Right planning and tracking with visual boards, WIP limits, reducing context.
Switching, prioritization, swim lanes.
Trunk based development, myflow, automation, streamlining things, force push considerations.
Shift left testings impact on velocity, the evolving QA role.
Shift left, security again, red blue teams as learning opportunities, code spaces for secure.
Dev and linking metrics back to business goals. Developer satisfaction is key to absolutely happy.
Effective engineers are productive engineers.
Now making sure we're building the right things, lean product development, lean.
Startup yes, using customer feedback, experimentation, build stuff people actually.
Need and want the build measure, learn.
Loop core concept, build an MVP, quickly, measure how users react, learn from it, iterate requires understanding your product, your market.
Business acumen for engineers increasingly important.
The guide suggests the business model Canvas as a tool for engineers to get better at product thinking.
Understanding the product life cycle too, innovators, early adopters.
Majority laggards. Knowing where your product fits helps guide strategy and experimentation.
Again ab testing for continuous.
Improvement, applying the scientific method, clear hypothesis, design and experiment, define independent, independent variables, use control groups, rigorous testing tools. For this mentions growth book Flagger as engineering focused options and again aligns with okr's experiments. Should help you learn and achieve your goals.
Okay. Wrapping up with GitHub for bigger organizations, teams and enterprises.
Covers the pricing tiers. Free Team Enterprise highlights enterprise security features like sam LSSO enterprise managed Users.
EMU, organizing teams within.
GitHub, horizontal vertical, nested teams, visible versus secret teams, managing access for outside collaborators too.
What about migrating to GitHub?
Discuss the strategies high fidelity, keep all history versus clean cutovers, start fresh mentions tools, GitHub Enterprise Importer, GEI Valet for azured DevOps, migration, branching, model changes might be needed if coming from something else.
And finally, why do so many big transformations fail?
Critical question? The guide points to lack of clear vision, not enough coaching, unsupportive culture, shares principles for success, ask forgiveness, You build it, you run it, fail early, embrace failure, collaborate, go fix, Treat servers like cattle. If it hurts, do it more often. Familiar classic DevOps wisdom, and be data driven, measure fine bottlenecks, focus improvements there, which brings.
Us back to DevOps culture itself.
The union of people, process products, built on learning, collaboration, ownership, that's the foundation.
Wow, okay, we have covered a ton of ground here.
We really have, from the nitty gritty of pull requests.
And automation all the way up to security, integration, metrics, lean principles, culture.
It's a comprehensive view.
And if there's one thing to really stick in your mind, remember that stat about company lifespan shrinking.
Yeah, that's a sobering one.
It just hammers home that being able to adapt to accelerate software delivery it's not a nice to have anymore. It's survival, it really is.
So we'd encourage you listening to dive deeper into whatever sparked your interests most today.
Check out the GitHub docs for the tools, look up those open source.
Projects, and think critically, how could these ideas apply to your team, your workflow. Maybe identify just one bottleneck, one small thing you could start improving.
Start small, iterate. So final thought to leave you with go. Given this relentless pace of change, our total reliance on software, how will these principles collaboration, automation continues improvement. How will they change not just software development, but maybe the whole way organizations operate and deliver value in the future. Think bigger than just code and deployments. What are the broader implications?
Hm hmm, something that chew on definitely.
Thanks for joining us for this deep dive.