About this talk
This talk addresses the flaws in the traditional software delivery life cycle, specifically focusing on the importance of integrating quality assurance and user acceptance testing early in the process. The speaker uses a fictional retail example, Bridget's Widgets, to illustrate how a lack of timely validation leads to costly errors and inefficiencies. They emphasize that simply adding AI to a broken process exacerbates existing issues rather than solving them. Instead, the speaker advocates for a 'shift left' strategy, promoting testing before merging code. By implementing automated testing environments for each pull request, teams can ensure higher quality outputs without the bottlenecks often associated with the traditional workflows. The speaker highlights how adopting these methodologies can enhance productivity, improve quality, and facilitate a more creative problem-solving environment within teams.
Full transcript
And, uh just want to start off with a little bit of a disclaimer. So, no matter where you are on the spectrum of AI, whether you're an optimist or a pessimist or maybe somewhere in between, or, you know, whether you're already shipping AI-generated code, or you're going to resist it as long as possible, you can still benefit from this talk. Um And that's because the traditional software
delivery life cycle is broken. And most of us don't even realize it. To illustrate this, I'd like to share a story. And rather than talk about software development, let's enter the neighborhood of make-believe. So, imagine with me a retail chain with stores all over the world called Bridget's Widgets. So, Bridget hires three widget designers, incredible designers. They dream up these amazing widgets, the most amazing widgets the
world has ever seen. And to make their these widget dreams come true, Bridget also hires a team of tinkerers, engineers, builders. So, the tinkerers receive these designs from the designers and descriptions of the designs, and they go into their workshops and begin working on each of these incredible widget designs. Once a tinkerer finishes one of these widgets, uh another tinkerer comes in and verifies that the widget
meets the spec that was provided by the designer. Once it meets that spec, they'll go ahead and box that widget up. And then they take those boxed widgets up and they uh pack them onto large container ships to be shipped out. After all the widgets are loaded onto the ship, you'd think we're ready to set sail, right? We're ready to ship these widgets off, but we've missed
a critical step in the process of building a widget. Up to this point, the widget designers have not even seen what's been built, right? And neither has Bridget. So, to solve this, Bridget hires some quality-minded folks that all want to ensure that these widgets live up to her high standards. So, after all the containers are loaded on the ship, Bridget, the designers, and these quality assurance engineers
climb aboard the ship, open each container, and investigate and validate the quality of each widget. Now, shifting back to software land, uh the process by which software goes from, you know, just an idea to actually live on the site is uh what's called soft the software delivery life cycle, uh or SDLC. And if you haven't heard this phrase before, it may sound fancy, but even if you're
a team of one that wears all the hats and deploys on Fridays with FTP, you have an SDLC. You may just not have it formalized, documented, and followed to the letter. It's the way you do things, and it lives inside your head alongside other things filed under things not to talk about at a party when someone asks you what you do for a living. So, here's a
depiction of what a typical software delivery life cycle looks like. An idea begins in the planning phase and progresses forward to a spec, to design, to development, and then verification, which includes automated testing and peer review. And after the code has been peer reviewed and automated tests have passed, the work gets merged in and eventually deployed to some environment where quality assurance and user acceptance testing occur.
Now, for for the purposes of the talk today, we're mostly just going to focus on this portion of the software delivery life cycle from the development forward. And now some of you are looking at this and you're thinking this is way over simplified. You've missed several steps in there. While others are thinking, what the heck is user acceptance testing? I've never heard of that before. So, to
the former group, congratudolences. Um you have a rigorous, formalized, perhaps complicated SDLC. Uh but to the latter group, to answer the question of what the heck is user acceptance testing, let's look at each of the three validation phases of this SDLC. We've got the verify step, the QA step, and the UAT step, the user acceptance testing step. Each of these validations phases is there to verify the
work that's been done, but each is doing so by answering a different question. In the verify phase, the question being answered is, was this thing built correctly? The engineers answer this question by doing peer review and automated tests. In the QA phase, the question being answered is, does the thing work And often added onto that is, did it break anything else? And QA engineers or maybe even
project managers or product owners, they or even perhaps the stakeholders themselves, they answer this question by manually testing it or by, you know, maybe there's a regression testing suite that they run against the the thing at this point. And then finally, we have the user acceptance testing phase. And the question being answered here is was the correct thing built? In other words, does this work meet business
needs or user needs? So, it's not about whether the code is technically sound or whether the approach works like on the QA phase, it's about do does this meet what the business needs? The question the earlier questions are objective questions. Do the tests pass? You know, does the thing work? But the UAT phase is more subjective and it's arguably the most critical question to answer. So, shifting
back to Bridget's Widgets, uh you may recall Bridget hires these quality assurance folks. And after all the widgets are created, boxed up, they're loaded onto the container ships. They climb aboard to ensure all the widgets pass muster. Now, inevitably, they find something wrong, right? That that's literally their job is to find things wrong. Um perhaps the tinkerer misunderstood what the designer's vision was or maybe they misunderstood
the spec sheet. Or perhaps the spec sheet itself was didn't do a thorough job of describing how the widget was supposed to work. And sometimes, as we just mentioned, perhaps everything was done perfectly. The designer and the spec sheet was great. The tinkerer built it exactly to spec. But once Bridget saw it in real life, she decided that it just not a good fit for her stores.
No matter the reason, we now have a problem. The problem is the widgets are already packed up and ready to ship out. The captain's ready to set sail. So, what's the team to do? Well, maybe Bridget asks the tinkerers to board the ship, work nights and weekends, and fix all those widgets that didn't pass muster. Or perhaps they're going to try to identify which containers have the
broken widgets and painstakingly and laboriously unload them from the ship, careful not to disturb any of the other containers with widgets in them. Or maybe they're just like this too tedious to try to unload these containers. We're just going to ship this as is and we're going to on the next ship that goes out, we're going to load the fixed widgets onto that and we'll fix it
later. No matter what they choose, uh this is kind of a dumpster fire process, right? Uh like when you look at it through this thinking through it this way of working, it's like why would we ever work this way? And the QA folks are exhausted. They've only had one day to review every single widget on the ship and they're meeting resistance from the tinkerers all along the
way with every issue they report. The designers are upset cuz their work is being shipped out in a shotty state and they feel like it reflects back on And the tinkerers are burned out. They've been working nights and weekends and they're feeling this pinch between, you know, trying to get things out as quickly as possible, but also meeting these standards that feel beyond their, you know, realistic
uh capabilities. And Bridget, she's worried about impact on revenue. She cares about her team. She knows that for everyone to keep their jobs, Bridget's Widgets needs to make money. So, shifting again back to software we see a similar pattern emerging, right? At first blush, what we've got here looks pretty straightforward. Code is written, a pull request is created uh for peer review, for automated tests run, it's
merged, and if QA and UAT pass, it gets deployed. But, we're thinking about this as if it was just one pull request. But, you know, we're often working in sprints. Let's say it's a 2-week sprint, and we've got lots of work that's all being done in that sprint. So, let's let's scale out this diagram a little bit to try to reflect what that looks So, here we've
got each of these additional develop and verify blocks represent a pull request being created by a developer. That once it's verified, it gets merged in. And at the end of the sprint, all this merged work is then deployed to stage. And inevitably, like we said, QA finds an issue, right? Or worst case, we're about to all hop on that phone call for the demo, and it's a
white screen of death on the staging server. Here we have our senior engineer trying to get things back online right before everyone joins the call. I like to call this uh dumpster fire demo days. I've experienced many. So, back to our demo here, you know, the demo day, even if just one of the pull requests was the problem, the whole release is blocked, right? This is just
like Bridget's ship, loaded up with all the widgets, the captain's ready to set sail, but if the release is shipped, it's shipped with the broken things, too. So, at this point, I often see three anti-patterns with how to mitigate the issue, right? This is by no means exhaustive, but the first one is the scrub the release. And this is where, you know, folks work nights and weekends
and try to get everything fixed. We're completely blocked right now, so somebody's got to figure it out and we're going to get this release out as soon as that's done. The second one is that reverting those PRs and, you know, going in there and trying to figure out which PR is dependent on the other PR and can we revert these safely? And it can be a little
dicey sometimes to try to figure this out. And then third one is just the just ship it, you know, and then we're going to hotfix this later. Right? So, this is the like we've got to get this release out the door. We've got things in there that need to go out right away. I know we've got this other thing that's broken. Somebody's going to have to work
late and try to get a hotfix out as soon as possible. So, does this um familiar to anyone? lots of hands raising. Uh and we're all just kind of like, this is fine, right? This is how we work, you know? This is the way things are. Um and Bridget's Widgets no different. They think this is just the way things are and changing it would be difficult and
expensive. Meanwhile, the team has just learned that a robot has been created that's going to help the tinkerers build widgets even faster than before. How's it going to do this? Well, it's going to hand them the right tools right when they need it. It's going to look at how other widgets have been built in the past and it's going to create prototypes of new widgets based on
previous widgets that have been built. And uh the designers are promised that there's going to be way less back and forth between the tinkers and the designers uh because it's working from all this knowledge of previous widgets. The tinkers are promised that the robots are going to free them up to work on the challenging and interesting things and also just be that much more productive. And the
QA folks are promised that these robots will actually be able to verify things before they get boxed up, so the quality is actually going to go up. And indeed, Bridget, she's promised that she'll get faster time to market, reduced costs, and since she's a business owner with integrity, she's hoping to be able to pay her team more based on the money that the additional revenue she's going
to generate. So, it's going to dramatically speed up the time that these tinkers can create new widgets. So, they get this robot, they plug it into their existing process, and the robot's cranking out prototypes, handing tools over at just the right moment, the workshop is humming. But, the containers are still getting packed up the same way. The ship is still being loaded the same way. The Bridget
and the QA folks, they're still climbing aboard at the very end, opening every single container, and they're still finding problems. Only now there's even more containers to inspect because the tinkers are producing widgets faster than ever before. The designers are now even more frustrated because twice as many widgets are being shipped that don't match their vision. The QA folks are drowning. They used to have 100 widgets
to inspect, and now they've got 200 widgets to inspect. And the tinkers have boxes piling up of returned widgets that they need to fix. she's spending more money, not less, because the cost of fixing mistakes after they're packed and loaded has gone up tremendously. So, again, back to uh software land. This is exactly what DORA found when they started looking into AI-assisted software development. So, DORA is
the DevOps Research and Assessment team. It's a team in the within the Google Cloud that conducts research on DevOps practices by surveying software engineers. What they found that is that for teams that have process problems, adding AI will actually make those problems worse, not better. So, if your process is broken, AI is going to make that process even more painful. Not only that, but if you've got
instability issues, they found that adding AI only increases instability. And like Bridget's Widgets, the process they have to build the widgets isn't ready for a robot to help them yet. It's not evolved there. In fact, by adding a robot, things only get worse. In other words, their bottleneck is going to become even more bottlenecky, if that's a word I can make up. To visualize this, you recall
this slide from earlier showing what a typical sprint looks like with our traditional software delivery life cycle. So, let's start using AI to increase the productivity of the engineering team. That might look like something like this. So, now we've got even more pull requests getting created, that much more code being generated. Looks great. Look at all this extra work that we're getting done. But, with more PRs
getting merged in that haven't passed QA and UAT, the risk of a problem being found and the release getting blocked goes up tremendously. So, it's this cruel paradox that we encounter that the harder you're pushing for efficiency and speed, the slower and more fragile the whole process becomes. Okay, so what are we to do? What's What do we do from here, right? So, to avoid this dumpster
fire development process, we need to move the QA and UAT steps to before the merge. This is what's called shifting left. And all sorts of things can be shifted The important part is identifying where your bottleneck is. And in our case, the bottleneck is performing Q and U QA and UAT on the staging server after work has already been merged in. So, let's look at what happens
if we shift QA and UAT to before the merge. So, now when a developer is done with their work and it has passed automated tests and peer review, then QA and user acceptance testing can occur. And only after that has passed, will the work get So, the question is Okay, how? How How do we QA something that hasn't been merged yet, right? And the answer is every
pull request needs its own environment before it ever touches your main branch. And we don't just need a description of the change. We don't need a screenshot in a Jira ticket. We need a real, running, fully functional environment that someone can click through, test, and say, "Yep, that's right." or "No, that's not what we want. That's not You know, it didn't didn't meet these criteria." And an
empty site with lorem ipsum doesn't tell you much, either. You know, QA folks, product owners, stakeholders, they need to see things in context. And real data is messy, right? So, these staging environments, if they're using real data, they're going to be able to catch bugs before they ever just reveal themselves only in that production environment. And if the process is manual, it inevitably becomes optional. And optional
steps get skipped, especially when the team's moving fast. We need these on every pull request, too, not just the big scary ones, every single one. There's a lot of teams that, okay, we've got this big thing, so we need to deploy it onto the staging server and test it out. But, I don't know if, like you, you've been bitten by just a minor dependency update that was
created by an automatic like Dependabot PR. Seemed very trivial, but how often are developers pulling those down onto their local environments to test them out? When every PR automatically gets an environment to test out, it you're going to catch things before they ever get merged in. Okay, so, let's see this in action. I'm going to show you this with Tugboat. That's the product that we built, because
that's exactly what this does. But, everything I'm about to show you is the pattern, not the product. I don't have another way of showing you it on someone else's product. So, it's not like I'm just showing you the the pattern of the way of working, and if you walk away from this talk and implement this with something else entirely, I will absolutely consider that a win. let's
hope the video loads. There we go. On the left, we have a GitHub pull request being created, and on the right, we have the Tugboat dashboard. I apologize if this is a little small, um but once once that pull request is created, Tugboat automatically clones an environment that is preceded with all of the sanitized data. And one of the first steps that that environment does, what Tugboat
does, is it merges whatever that pull request branch is into the target branch. And that in and of itself is going to catch a lot of things that you might not catch if you were to just pull it down onto some environment with just that branch, cuz you're then integrating that branch in with other work that may have preceded uh into the main branch. And next, Tugboat
then runs all the same deployment steps that would run for a production deployment. So, this all simulates the full workflow of what would it be like if this single pull request was deployed to production right now. And once it finishes, it's maybe hard to see, but it posts a link back to the environment, so anybody can click that link, and this is the DrupYard Meridian theme that
we're that we're using here for this demo. Um anyone can click that link, whether it's a project manager, product owner, QA, stakeholders, anyone that needs to validate the acceptance criteria or sign off on the work. now we have these automated testing environments on every pull request. Let's go back to our sprint and see what happens. We still need to scale this out, right? Just like we did
before, we're going to scale it out. We've got our healthy software delivery life cycle, and now we've got additional branches being created, additional pull requests. We're increasing the number of pull Okay, what happens when things go wrong? It could be any reason. You know, it could be the technical side of things breaks, or it could be a QA, you know, QA engineer finds something broken, or user
acceptance testing. We've just decided we're not going to do this work. It doesn't matter where things break in this process. No matter what happens, your main branch is still ready to be deployed. Your release is never blocked with this this way of working this approach of ensuring that your stable branch is always tested and ready to ship is what's called continuous delivery. So, back in Bridget's Widgets,
the land of make-believe, the only items that are loaded onto the ship are the ones that have been 100% verified by the designers, by Bridget, by the QA folks. And so now, when the AI robots get in there and improve the productivity of your development teams, you're already equipped with a streamlined and scalable back to the DORA report, the remarkable thing is that once you've got this
hot with automated testing environments, what the report shows is that adding automation and AI, it doesn't just increase the speed, but it also increases the quality and stability at that point. Previously, we saw the reverse happening where if you've got instability, AI's only going to increase that instability. Once we've got added stability into the workflow, now AI will actually increase the stability that's there. This is pretty
amazing when you think about it. It's one of those rare like have your cake and eat it two moments, right? Which never happen in the real world. So, we fix Bridget's process. We've shifted left. QA happens in the workshop, not on the ship. Bridget and the designers see what's being built before it's boxed up. The robots help the entire team try new ideas. And the addition of
the robots now makes the whole team faster and efficient and also increases the quality of the widgets that are being built. Now, what's interesting and honestly inspiring to me is that the bottleneck doesn't disappear with this workflow. And in fact, it moves. It It moves to where exactly where it should be. So, with the process in the broken process, the bottleneck is a technical It's can we
get this built, tested, packed, shipped without everything falling apart? That's a logistics problem. That's a That's a plumbing problem. And your most creative, most talented people are spending their energy fighting plumbing. But when you shift left, when you do that QA and that UAT before merge, when you're testing all of those pull requests before they get merged in, this technical bottleneck dissolves and and what's left is
the judgment call. It's the human one. The why. Why are we building this widget? Who is it for? Does it make someone's life better? Does it belong on our shelves? David Poll, uh, senior director of engineering at GitHub, published an article recently coming to a similar conclusion. He says, "If there's not If there's a bottleneck, it's not code review and it's not production validation. It's judgment." He
emphasizes that AI doesn't remove the bottleneck. Instead, it just up levels where humans can operate to the point of that When I talk about uh talk with folks about AI, uh the movie Wall-E comes up a bunch. Uh if you haven't seen it, there's a scene set hundreds of year in the future where humans have let robots handle everything, right? So, and I I mean everything. People
are morbidly overweight being shuttled around in like autonomous hover chairs, drinking their meals through straws. They don't walk, they don't make things, they just consume. They've been optimized into passivity. The humans aren't making judgment calls anymore. And I get it. When I talk with those folks like that's a real fear. But I don't think it's inevitable. I think that's what happens when you just mindlessly use AI
just to make a buck or in the interest of comfort or convenience. I recently heard uh Dave Look from Chromatic, if you don't know uh Chromatic, they're a Drupal agency. I heard heard him recently say that business is art. And I think what he means is that business at its best is a creative And if you're doing it the way Dave does, you're waking up in the
morning striving to make the world a better place, to help and inspire others. And that's not a logistics problem. That's not a a plumbing problem. That's a deeply human one. And there's this this scene at the end of Wall-E where the humans take a seedling and they plant it in the ground and they tell their chil- children, "This is farming." And uh by shifting left, we move
the bottleneck back to the point where humans are saying yes or no to what beautiful thing they want to create, to protect, to steward in the The bottleneck stops being a technical one. It becomes a creative one. And that's exactly where it should be. So, we take the question of can we build it faster off the table? And the question is, should we build it at all?
And no robot no robot can answer that for you. Questions? Thoughts? Ideas? Yeah, in the back. you automated the process of making an environment for every every pull request. Mhm. But if one of those gets merged, do all of the other environments need to be updated to reflect the the the parent branch has changed? Right. So, the question is um you've automated the spinning up these environments
for pull requests. If one of those gets merged, how does that affect the other pull requests that are open? That is uh that is a reason actually for still having the staging server in the Um so, you can have you've got all these things that are being tested in isolation. Um and then you still, you know, it's good to still have a smoke test environment where you
can take all these things that have been merged in and test them all together before the release goes out. That's my opinion. There is a way, you know, you can still automate any one thing is merged in, all the other pull requests get updated as well, the other pull pull request previews. However, with a fast-moving team, you may just constantly be rebuilding things and interrupting other people
working, so there is there is that kind of balance to find with how much you automate that. Yeah. Is there a way to prevent merging into your Git without approval from like some other system that's saying it was approved, now you can merge it. Is there So, the question was, is there a way of preventing things from being merged in from a pull prematurely, so making sure
that they're verified? Is that right? Um that's a good question. I I haven't seen anyone doing that like where it's an explicit Uh Shawn In In GitHub, you can set it to be a uh a deploy that's built properly. Right. >> And then you can have your pull request has to be approved by someone as part of like the rules in order to merge it in. Okay.
So, it's also like a normal process, but it it's still being manual. It can't be like that automated. Oh, hey, there's approval in Tugboat, so therefore Right. it's approved for the pull request. >> Yeah, for the manual QA and UAT side of things, there's there's not anything in Tugboat that does that, but you would have to, you know, have that be a part of your process, so.
>> Okay. Over here? Two questions. I come from academic, it's a low-budget multi-site uh type situation. >> Uh-huh. We rely on kind of picking and choosing what sites are in dev to test on uh instead of loading all 1,300. Mhm. Uh uh we have authentication that connects with a SAML server. so how does authentication happen then in these uh on-demand environments, basically? Yeah, so the question is,
you know, kind of twofold. There's They're in the uh university system, higher ed it sounds like. Is that right? Yeah. So and they've got thousands of sites and usually in their dev um they'll only pull a handful of those in there to test. Um so part of the question is, how do you handle that? And then what was the other part, sorry? The Just handling authentication for
>> Right. This So the SAML authentication. So you've got an any sort of integration with a third-party something. Um and a lot of times that's like the domain-based like allow-listed thing that only these certain domains can use. Um and you've got to kind of wrestle with CORS headers and all that sort of stuff. Um so for the for the former sort of problem space, uh we see
a similar thing happening for our Tugboat customers where they'll have, say, 10 to 15 of their multi-site sites that that are like kind of their high-priority sites that they'll test there. Cuz it's it is somewhat unreasonable to say, "We're going to test this across across all 1,300 sites, right?" Um so, you know, finding the right balance there of like we need to make sure, you know, these
are our these are our um customers that are going to be maybe the noisiest if something breaks. We're going to prioritize those ones, um have those in and really make sure nothing breaks for those folks. Um and then as far as the integration with third-party things, we do have uh Tugboat has a way to to have uh your own custom domain pointed there as well, so you
could have you know, hogwarts.edu and it'd be, you know, like the Tugboat subdomain or something like that on front of that, so um that's one way I've seen folks do it or they'll have, you know, they will have the star.tugboatqa.com domain added in their allow list in their third-party API integration, so. In the back? Yeah, if you have pull requests with dependencies, would you use an integration
branch and then you test UAT and QA and stack Yeah, the question is if you have a pull request with dependencies, would you have like an integration branch? And so I think what Correct me if I'm wrong, what you're kind of asking is like let's say you've got a larger work stream that's being worked on and maybe you have multiple developers working on different aspects of that
work stream. And you want to all have that work merged in, but you're not quite ready to merge it into the main branch. Is that kind of what you're asking? Yeah, okay. Um, so yeah, with Tugboat at least you can have multiple what they're called base previews. So if you have a long-running feature branch that that lots of work is being branched off of and merged into,
you can have a base preview for that specific branch and then that merge process that I was talking about would take uh you know, it'd look at whatever the pull request target branch is and that's where the merge is being performed to. So, yeah. Came up with another question. So, what if priority shift on a particular uh task or something like that and we want to kind
of pull it out from active state. Would that be closing the pull requests uh leaving the branch maybe for somebody else to pick it up later or how's the process of like removing it? Yeah, so the question is like what if you know you've got this you've created this pull request and then it's decided we're not doing this or something and so we need to remove it.
The way Tugboat handles that is if you close a pull request it'll automatically delete that environment that's associated with it. You can disable that if you don't want it to do that but it is does by default it does its own clean up after a pull request is either merged or deleted or whatever. So. >> Is there a limit how long these virtual environments can be stood
up for? So the question was is there a limit how long they're stood up for? There is a way with our API to set a limit so you could say, you know, if this after 5 days is still here just go ahead and delete it or 30 days but by default if as long as the pull request is open that that environment is there and available. So
I'm excuse me, perhaps I'm missing something but how are you actually able to automate the UAT portion of it considering that's subjective? Yeah, so the question was how are you able to automate the UAT part since that's subjective and we're not automating the UAT part. The The only thing that we're automating is the ability for UAT to happen prior to that merge occurring. So the UAT still
you know, you've you now have a link for UAT to occur on and so then what what typically happens is maybe it's back on the Jira issue or something or it's shared with the stakeholder at that point and say check this out, click around, make sure that's what you meant. Did you when you said you wanted the logo bigger is this what you meant? And they have
a link where they can pull that up on their phone or their tablet or wherever and actually see. Is that >> So they're having to check through, you you 40 pull requests instead of just one final result. It depends on, you know, it depends on the stakeholders. So, they they were asking, do they have to they have to check through all 40 of them? I think it
just depends on the the you know, how important that work is, right? It doesn't mean they have to check on all those things, but it also depends on how involved the stakeholder is. Sometimes stakeholders are not not as involved as others, and they just want it, you know, they want you to kind of they want to pass down what they want uh and describe it to you,
and then they're going to see it on prod eventually and like then inevitably the UAT happens on prod with stakeholders that are a little more hands-off, so. Do you think there's any possibility that AI could be used to sort of Mhm. give a best guess? Do you think that this satisfies UAT requirements? Yeah, so the the additional part of it was, do you think AI could help
out with the actual user acceptance testing? And I would say absolutely so long as the acceptance criteria are well documented. Because it really all goes back to that. If you've got great acceptance criteria in there um then yes, you could point AI at that, but if your acceptance criteria it it isn't good, then it's just going to validate incorrect acceptance criteria, so. And again, it like like
you were mentioning, it's subjective, right? So, um is AI going to be able to answer Um it just depends on probably what the ticket is. If it is, is the logo bigger? Then yeah, it could probably determine that. But, is it if it was more something like, will my customers like The stakeholder's probably going to need to click around and make that judgment call themselves. Question specific
to Tugboat. Is in case of Tugboat, you're using your own Docker container or Tugboat has an image? We have uh we have images that are So, uh on the Docker side of things, do we have are we able to use our own Docker images or are we using Tugboat Docker images? Is that right? Yeah. So, Tugboat does have its own Docker images that are specifically made to
be compatible with Tugboat. You can use private Docker images that you can wire up your own Docker registry and you can use your own images. There are a few compatibility things that you may need to change in order to make sure it works in Tugboat, but um you can use your own images. And if you're running automation in Docker, does Tugboat provide uh parallel processing so that
and also storage of data or whatever you run through the coordination? the question is if you're running automation with the with the Docker images, is that right? if your automation scripts are running in Docker Mhm. and with the virtualization of Tugboat, um does it allow you to run those in a parallel uh steps? And does Tugboat provide any processing or storage? Does So, yeah, so the question
is does Tugboat um provide any additional processing or storage or capabilities for parallel runs? Uh it does depend on the tier in Tugboat for parallelization. So, if you you know, in terms of concurrency of builds. but I'm not sure I'm fully following the part about automation. Typically, folks don't run automated tests. I'm not sure if you're talking about automated tests on on Tugboat. Um usually, they'll use
like CircleCI or GitHub Actions or GitLab pipeline CI or Bitbucket pipelines or something like that to run those automated tests. Is Yeah, yeah, yeah, okay. So. Other questions? Well, since we talked so much about dumpster fires, I did want to call out Amber Matz. Amber Matz works for Tugboat. She's been crocheting little dumpster fires. If you're interested in crocheting your own dumpster fire, come by the Tugboat
booth. She's got little They're actually all out. I gave them Oh, well Yeah. You can still get the link to where they Um Do you have directions? About the pattern. >> Yeah, she's got the pattern and yeah. And also I'd really appreciate feedback on the session. That would be super helpful. So. Thank you. Thank you.
