DevOps Launchpad Live: How to improve your Salesforce deployment success rate

Share with

Description

In our first DevOps Launchpad Live webinar, DevOps Advocate Rob Cowell covers deployment success — a pain point for many teams developing on Salesforce. Find out why you need to master reliable deployments in order to reap the benefits of DevOps — and come away with practical advice on how to increase your team’s deployment success rate and get your processes in the best shape possible.

Want to upskill in Salesforce DevOps and get certified for yourself? Join the leading training platform for Salesforce DevOps today.

Learn more about deployment success with Gearset:

Related videos:

Transcript

Good morning, afternoon or evening, depending on where folks are. I think we've got quite a lot of mornings going on in the US.

So this is our first DevOps Launchpad Live webinar and today's topic is gonna be on improving deployment success rates for Salesforce with a bit of help from DevOps.

So we're gonna be discussing strategies and best practices that can help you achieve higher success rates in deploying your Salesforce applications.

Now, throughout the webinar, I encourage folks to actively participate, ask questions, share your experiences in the chat box, and then there's gonna be a dedicated Q and A at the end of the session as well. So if you've got any queries, feel free to add the questions in the chat or in the Q and A panel. There should be a little box at the bottom of your screen. And we'll try and make this webinar a little interactive and enriching for everyone.

So a little about me.

I am Rob Cowell. I am one of the DevOps advocates here at Gearset, and I've been in the Salesforce world for about twelve or thirteen years in variety of roles, mostly as a developer or an architect or somewhere in between the two. So I've done quite a lot of deployments over the years, some good ones, some not so great, I'll be honest, but that's kind of where we learn. And hopefully we can start looking at some of the things that I have learned over that time and see how we can apply them to everyone's deployments.

So in the webinar, we're gonna cover a range of topics that are crucial for improving that success rate for your Salesforce DevOps deployments.

We'll explore some architectural best practice, the benefits of being organized and some documentation techniques, as well as test driven development and the importance of early feedback loops.

The goal is to provide you with some actionable insights and strategies that you can apply to your own Salesforce deployment processes.

So let's begin by understanding the significance of DevOps in the context of Salesforce deployments.

DevOps is a combination of development and operations. It focuses on collaboration, automation, and continuous improvement to streamline your software delivery.

Implementing DevOps practices in your Salesforce deployments can help organizations achieve faster, more reliable and error free releases.

But before we dive into those details, I'd like to emphasize the importance of a well planned and structured approach to those Salesforce deployments.

As we all know, deploying changes to a complex system such as Salesforce can be challenging and prone to errors if not executed properly.

By following some of the best practices and strategies that we'll discuss today, you can significantly increase your chances of those successful deployments.

So without further ado, let's dive into our first topic, good architectural best practices. This will be about the importance of design first approach, understanding the impact of your changes, collaboration, and managing those external dependencies.

So let's make a start.

A solid architectural foundation is crucial for smooth and error free deployments.

Let's have a look at some of those key considerations and strategies that can help you achieve that.

To begin, let's emphasize the importance of a design first approach. Before we make any changes, it's crucial to have a clear plan and a design in place.

This will involve analysing the requirements, understanding the desired outcomes and creating a blueprint of the changes that you want to implement.

Another critical aspect is understanding the impact of your changes. It's essential to assess what needs to be changed and evaluate the potential ripple effects on other components and functionality.

This foresight helps in avoiding unexpected issues and allows for a more controlled and efficient deployment process.

Collaboration and cultural awareness plays a vital role in architectural best practice too. Keeping stakeholders and team members informed and involved throughout that entire process fosters a collaborative environment.

By promoting open communication and sharing knowledge, you can build a culture of collaboration that enhances the success of those deployments.

By managing external dependencies, you'll see how crucial it is for ensuring smooth deployments.

Identifying and addressing any dependencies on external systems, integrations, or third party tools is a key skill. Consider how changes in these dependencies might impact your Salesforce deployment and plan around them accordingly.

Using a single repository for version control is a recommended practice in DevOps. It provides a centralized and streamlined approach to managing your Salesforce metadata.

This enables collaboration, versioning and tracking of changes, ultimately enhancing those deployment success rates.

Lastly, staying aware of any other ongoing work by other team members is important to help avoid conflicts and streamline those deployments.

Regularly communicate with other teams or developers working on related components or functionality so that you understand what work is going on both around and inside your own work.

This awareness will help identify potential conflicts and it coordinates those efforts to ensure smoother deployments.

So, so far we've explored some of the key architectural best practices for Salesforce deployments.

By following these, you'll be better equipped to design, plan and execute successful deployments using Salesforce DevOps principles.

In the next section, we're gonna focus on the importance of organization and documentation in those deployments.

We'll discuss techniques for tracking metadata changes using tools such as Gearset and maintaining comprehensive documentation.

So if we delve into the critical aspects of organization and documentation of Salesforce deployments, a few things come out. Being organized and maintaining the documentation are key factors in ensuring successful deployments.

First things first, it's crucial to know the metadata components that are involved in the deployment. We need a clear understanding of what we're modifying or introducing. This will allow us to track and manage those changes effectively throughout the entire deployment process from development through testing and all the way out to production.

It's at this point that we realize documentation is our friend. It's essential to maintain comprehensive documentation of the changes that we're making.

This way we've got a clear record of what modifications were done.

Documenting our Salesforce configuration or code base provides better visibility and traceability, helping us troubleshoot and understand the changes that we've made.

To keep things organized, you can take advantage of platforms like Gearset. It'll allow you to track metadata changes, assuring that nothing's missed along the way. It gives us visibility into the changes that are made to our Salesforce org, helps us detect conflicts and manage our deployments more efficiently.

For smoother organization and collaboration, we can make use of project management tools such as Jira or similar platforms.

These tools provide a centralized space for tracking tasks, issues, and requirements related to our Salesforce deployments.

By using them, we can streamline that organization, assign responsibilities, and track the progress, ensuring a more streamlined process across the whole life cycle.

Building reusable components and libraries is another smart move for efficient organization.

By creating a collection of commonly used components, we can reduce redundant development efforts and promote consistency across multiple projects.

Reusing these components doesn't just save time, but it also means you have a standardized approach for your development and deployment.

So to quickly recap that, we've seen the importance of organization and documentation by knowing what metadata components we're likely to affect, documenting those changes comprehensively and using solutions that can improve the organization of that such as Gearset, such as Jira for the project management side of things and by building reusable libraries of components, again, we can completely transform our deployment success rates.

So next we'll focus on two other critical factors that can help drive successful deployments, test driven development and early feedback loops.

Implementing test driven development or TDD and involving end users and stakeholders early in that testing process are key practices to getting reliable and efficient deployments.

TDD plays a significant role in ensuring deployment success. It emphasizes writing tests before the code or the declarative changes, and it provides a solid foundation for your development work.

By following TDD principles, you can build confidence in the quality of your code changes and reduce the chances of introducing critical issues during that deployment.

Testing early and frequently throughout the entire process is crucial.

If you wait until the final stages of deployment before you do your comprehensive testing, it can lead to delays and unexpected issues.

But by incorporating the testing at the various stages of the development cycle, you can catch and address those issues earlier.

Unit testing, functional system testing, and user acceptance testing are all essential components of that testing strategy.

Unit testing will ensure that the individual components of your application work correctly.

Functional testing will validate the overall functionality and the behavior of the system as a whole.

And then user acceptance testing will involve the end users and your stakeholders in testing the application to ensure that it meets their requirements and expectations.

So shifting those testing activities to earlier stages of development is recommended and it's often referred to as a shift left approach.

By bringing the testing activities in earlier in that development cycle you can identify and address them sooner and it reduces the impact on subsequent stages.

Involving the end users in that process allows you to validate functionality and gain that earlier feedback.

If you give them access to a development or testing environment that allows them to test real world scenarios, then their involvement will ensure that the application aligns with their requirements and expectations and it just reduces issues and pushback during the production deployment.

So hopefully that will allow you to appreciate the significance of that test driven development approach and the importance of testing early, frequently and having stakeholders and end users involved.

By adopting like these practices, you can build confidence in the quality of your work, can catch the issues early and you can ensure that they meet the requirements.

And it's important to maintain a mindset of error prevention and troubleshooting into Salesforce deployments. If you have a proactive approach and anticipate potential issues, you're going to minimize errors and promote quality and reliability.

That ability to anticipate the potential issues and failures is key to avoiding the pitfalls in your deployments.

If you encourage your development teams to think critically about possible problems and challenges that might arise during the deployment process.

If you take this approach, you can take preventative measures and it minimizes the impact that those issues may have on your deployments.

But also consider the broader impact that they may have on the system.

Think beyond the immediate scope of your specific changes and assess how it might impact other functionalities, integrations or dependencies.

If you take this more holistic approach and consider future needs and other dependencies, you can ensure that your changes are more aligned with the long term goals of your Salesforce deployment.

A term often used is defensive development. And these strategies are essential to minimize errors and bugs in your code base.

Encourage your developers to write robust code that handles potential edge cases, errors, and exceptions gracefully. Implement error handling mechanisms, perform input validation, and adopt defensive coding practices to make your code more resilient.

Documenting any errors and lessons learned during that process is crucial for continuous improvement. So encourage your teams to document errors, challenges, and unexpected issues they encountered during deployments and strategies for avoiding them for subsequent deployments.

The documentation will serve as a valuable resource for that future reference.

And it's essential to foster a culture where developers take ownership of quality and reliability.

So encourage your team to prioritize that testing, code reviews, and adhering to coding standards.

Emphasize the importance of writing clean, maintainable code and take responsibility for the quality of their work.

Finally, let's explore some of the advantages of testing in earlier stages, selective testing during iterative development, gathering feedback, incorporating those feedback loops and iterating on the entire development process.

By incorporating that feedback from stakeholders and end users in the early stages of development, from the testing that we talked about earlier, we can enhance our deployments and drive continuous improvement.

Testing in the earlier stages of development cycle brings a whole number of advantages. It allows us to catch the issues earlier, reducing the impact later down the line.

Early testing also allows you to validate the functionality, identify potential problems and align the solution with desired outcomes, increasing your chances of hitting it right first time.

And that feedback from the stakeholders and end users is invaluable because their insights and perspectives will help you refine the solution and help nail meeting their requirements.

But you also create a collaborative environment between the end users and the development teams, and it fosters a shared understanding and a more mutual sense of ownership.

Incorporating those feedback loops is essential for the continuous improvement aspect.

By actively seeking out and integrating that feedback into your development process, you can identify areas for enhancement and get those issues and concerns addressed much earlier on.

It's a key aspect of DevOps. Iterating and refining helps us form that DevOps loop that many folks will have seen as a diagram.

By continuously learning from our deployments and incorporating improvements, we create that continuous improvement culture and overall deliver higher quality solutions.

So throughout this session, we've explored a variety of topics and strategies that can help improve the success rate of your Salesforce deployment. So let's have a quick recap on some of the key points that we've looked at and summarize some of the main takeaways.

First and foremost, we emphasise the importance of a good architectural practice. A design first approach, understanding the impact of our changes and managing the external dependencies are crucial.

Organization and documentation will play a vital role in streamlining those deployments. If you know the metadata components involved and you use DevOps tools such as Gearset, maintaining comprehensive documentation and making use of project management tools such as JIRA, they all contribute to improved success rates.

We also discussed the significance of test driven development and early feedback loops. By implementing these, testing early and frequently, and getting end users and stakeholders involved, you can improve the quality and functionality of your deployments.

We also looked at developing a mindset for error prevention and troubleshooting by practicing defensive development, considering the broader impact of changes, documenting our errors and lessons learned and encouraging ownership of quality and reliability will all also contribute to successful deployments.

But it's important to remember that achieving those successful deployments is an ongoing journey. DevOps is a mindset rather than a hard and fast rule. And it's a set of practices that will require continuous improvement and adaptation of your organization's specific needs. There's no one right way to do DevOps.

So I hope that the insights and the strategies that we're sharing today will empower you to improve those deployment success rates for Salesforce using DevOps.

As you apply the practices in your own deployments, remember to measure your progress and adjust your approach accordingly. Each organization's DevOps journey is unique and it's important to tailor it for your specific context.

Now we encourage you to continue learning and exploring additional resources that'll help deepen your understanding of DevOps and how it applies to Salesforce deployments.

Keep in mind that building a culture of collaboration, continuous improvement, and quality assurance is at the core of successful DevOps. It's not always about the technology, it's about the culture.

So thanks folks for your participation in the webinar today. We hope that you found some of the information here valuable and you can apply it to your own deployments.

If you've got any further questions or you need additional assistance, as well as our Q and A today, you're always free to reach out to us here at Gearset.

We're here to support you in your journey towards that successful Salesforce deployment. And I'd also encourage you to explore some of the solutions that can make things a lot easier.

We do offer a thirty day free trial for all of our features. There's no limitations of functionality there. So you can really sort of see how pain free things can be using DevOps.

And of course, with this being Launchpad Live, don't forget, of course, to explore the modules on DevOps Launchpad if you want to understand some of those DevOps concepts a little deeper. It's a free resource for you and your teams that you can take advantage of.

Now, remember, with the right approach mindset, you can significantly improve those deployment success rates and get even greater value to your organization even faster.

And hopefully the next time that we catch up with folks, we can see that the deployment success poll that we did at the start of the webinar will have some far greater successes in there.

So at this point, that's plenty of talking from me and we can have a look at some of the questions that may have come up in the session and you can drop more into the Q and A box if necessary.

Thank you very much.

Thank you, Rob. I think we've had a few questions come in so far.

So first one might be a bit of a tricky one.

You spoke about the importance of documentation, but what do you do if nobody in the team has time to document the errors and the vital steps? What would your advice be there?

I think that there's a couple of approaches that you could potentially take to that one.

Top of the shop, would say that some of that speaks to a cultural issue and some of those challenges are around engaging with the stakeholders and leadership and saying, you know, much of what I've been saying about how by investing the time in doing the documentation and carving out time as part of a normal sprint cycle, for example, to document as we go along, I think, you know, becomes second nature.

So I would always encourage, you know, as part of kind of designing a release process to actually bake in time for that. Now that's obviously the cultural aspect. On the technical side, there are potentially some shortcuts.

There's no full shortcut, but I think tools that are able to footprint and document your org to a degree in an automated fashion can help you get some of that way. We work quite often with the good folks over at Elements Cloud who provide a tool that does much of that and they'd be happy to sort of advise you. I don't want to speak too much on their behalf but I've heard great things about it and I know it's an extremely powerful tool.

But I think just to kind of sum that up, a shorter answer potentially could be little and often rather than expect people to spend a day or an afternoon or whatever just doing nothing but documentation. If you do little bits as you go along, much like you do, I guess with code comments, you'd be surprised how much documentation will build up over time. Again, it's an incremental iterative process. It's not a big bang thing.

Thank you. That's really helpful.

A couple more questions on unit testing. So can I improve my chances by only running some of the unit tests when you deploy?

Absolutely, yeah. So as folks may know, Salesforce kind of mandates a minimum of seventy five percent test coverage for production deployments.

And as your organization grows and grows, you're going to have more and more tests that need running, and that will increase the amount of time it takes to do a deployment. Now, there's two approaches we can take here.

If you want to save that time, you can absolutely have a selective test. And as long as it covers the changes that you're deploying to that seventy five percent plus benchmark, then it is possible to say, okay, I only want to run the tests that are relevant to what I'm deploying.

However, coming back to what I was saying earlier around test early, test often, think about the bigger picture, I still think that not necessarily at sort of go live production day, because that's probably the wrong time to be doing it. But I think earlier in that process, find time to actually do a more comprehensive test run at some point when it's less critical from a time perspective, because that will lend itself to that bigger picture, making sure that what you've introduced doesn't inadvertently impact something else elsewhere in the org. So yeah, you can save time, but choose when to save that time strategically.

Good advice. Another question on unit tests: If I'm just deploying config, not code, can you skip running unit tests?

Yeah, and that's an interesting one that's kind of similar to that last question. So historically, unit tests have been very much leaning towards the pro code side of things.

And, you know, it is an enforced requirement. If you're developing a flow or even just doing some field changes, maybe you've changed the length of a field, maybe you've added a validation rule. That's one that used to trip me up quite a lot.

You don't know what else in the org is potentially depending on those changes or those items, those metadata pieces that you've changed.

And so it's always a good idea to at least once run your suite of unit tests just to make sure you haven't broken anything. A case in point there is I was working with a client in previous life before Gearset and they'd introduced a new validation rule on a field and the unit test had been written to populate that field that didn't meet those new criteria and I wasn't told about the new criteria. So of course the unit test failed, but by running that unit test earlier in the development process or encouraging folks that are making declarative changes to run the tests. It's very quick and easy to identify those little hiccups earlier in life cycle before they become a bigger problem.

Great. Thank you very much, Rob. I've got a question from Sadeepa, not necessarily specific to deployments, but I think an interesting topic for everyone looking to further their career. She's asked how to become a Salesforce architect and how much time it will take?' So any advice you have there would be very willingly received, I think.

Okay, so there's a couple of approaches to the concept of a Salesforce architect.

Have had roles where in my job title I have been a Salesforce architect, I think I was a technical architect, but I wasn't a certified technical architect. I think a lot of folks are possibly conflating the two things together. So it's possible to be an architect as a role or as a way of thinking, which I'll come back to in a second, without necessarily going through the certification process. I know it is seen as the certification pinnacle of people's understanding of Salesforce.

But coming back to what I was saying about sort of an architect mindset, I think there's an element of that that everybody can adopt, you know, whether they're just starting as an admin or a developer or whether they're sort of further along in that process. And the key is, coming back to some of the things I was saying earlier about thinking bigger picture, that's a big part of being an architect. So it's thinking, okay, this change, what is it going to impact? What elements am I going to need to hit with, what do I need to change?

You know, what piece of functionality within a broader organisation is it going to impact? And by going through those thought processes and taking a more measured, careful approach and thinking design first, implement second, much like, you know, sort of carpenters would, you know, measure twice, cut once, I think is the same. Know, using that kind of mindset means that already you're thinking like an architect. And if you continue to do that and demonstrate that better understanding to the projects that you're doing, you're well on your way to becoming an architect.

Now, as for the certification side of things, yep, there absolutely is a track.

There are certifications that make up the requirements for the Salesforce technical architect that you have to get along the way. Trailhead is the canonical resource for learning that, but there's also great resources out there from the community. There's focus on force. So if you want to take the more sort of certification based approach to that, those absolutely exist.

But take your time, it's not a race to the top and just continue growing your experience, continue working with the platform. Most folks learn best through doing rather than just reading and it'll happen for you.

Very solid advice. I've got a question on CPQ changes, I think strikes fear into the heart of a lot of Salesforce professionals.

I often have to deploy CPQ changes which fail more than normal Salesforce changes. Do you have any advice on this?

Yeah. So CPQ is an interesting beast.

And for folks that are not familiar with that one, CBQ is configure price quote.

It's another one of these kind of Salesforce functionalities that came in via virtue of acquisition. And so it is a little specialist, but one of the key considerations for CPQ is that a lot of the configuration isn't just in the metadata that you'd normally deploy.

A lot of that is done in the data as well. So for example, you know, the objects that contain the structure of your CPQ information will be metadata as normal, but a lot of the way that you do things like setting up price books for setting up pricing rules, quote templates and all that type of stuff that's very specific to CPQ will be in data. So you have to think about actually when I'm deploying CPQ changes, I need to be able to deploy both metadata and data.

And then there's the additional complexity that within that data, there's gonna be lookups and relationships between those objects. And that's again, in data with IDs as a lot of Salesforce folks will know.

So when it comes to deploying those changes between environments, you need to make sure that you maintain those relationships and kind of keep the integrity of that data model together, which can be very tricky to do.

Folks have kind of maintained huge spreadsheets to track all of this and they've used data loaders and various tools.

The good news is, and I'm going to use the G word again, even though I'm not necessarily in sales, but yes, Gearset does do CPQ particularly well because it keeps in mind all those considerations. We have a capability of maintaining and preserving those relationships within the data, which will hopefully make folks a lot easier with CPQ deployments.

Thank you. Yeah, those CPQ deployments do seem to pose quite a challenge for people.

That's why CPQ folks get particularly good rates for implementing them.

We've got a question from a new DevOps Centre user, so DevOps Centre is fairly recently made available to everyone. Do you have best practice recommendations for which types of metadata should be ignored during the configuration of a pipeline or repo?

Yeah, so that's a good question. And, you know, I think, you know, the answer is not necessarily specific to DevOps Centre. I think there's some good best practice, you know, regardless of the tooling that you're using there when it comes to what metadata to have in or out of scope. And, you know, we've done some sessions on version control that pick up on some of that as well.

So I would say start looking at what you're using on a day to day basis. Most orgs will have a huge dependency on account contact, probably opportunity if they're a Sales Cloud user or case if they're a Service Cloud user. There'll be a whole bunch of custom objects that are specific to your org that are absolutely critical to the working of your business.

So those should be in. But in terms of things to ignore, there's some easy wins.

So there are for any given Salesforce object, there can be what's called history tables and sharing tables or objects. And these are basically kind of tracking as the name was just the history of data changes and those are very high traffic and you're not really gonna gain a lot from just shifting that across because they're gonna change quite a lot on the data side, but the structure of that doesn't really change too often. So those are probably a good candidate to go. But then coming back to what I was saying about, you know, the nature of your specific org, you know, look at what is key to your organization and look at stuff that's more used for holding static data or lookup data that changes very, very rarely.

Do you need to include those in scope? I think there's an overall principle of, you know, if you make the target surface area, I. E. That the scope of things that you're looking at to move around your orgs on a regular basis as small as possible, then there's less work for the DevOps process to use regardless of tool, which means that it's gonna run a lot quicker and smoother for you.

Hopefully that answers that. I haven't done a lot with DevOps center, but I've seen a few presentations and I think those principles are equally applicable there too.

Great, thank you, Rob. Yes, there's always different on different platforms, so it's good to try different things out and there's best practices that I'm sure can apply across the board as well.

Somebody asked in the chat if we could share the results of the poll, so I was just gonna share those.

Yep.

Sure. I thought I would ask you if there was anything on there that's particularly surprising. So I think we discussed as people were joining that it's good that nobody's on zero percent and nobody's on one hundred percent, so everyone's in the middle, but any of the challenges whether you're surprised to see anything there?

Yeah. Let me just scroll that little window down a little. I must admit I overlooked the second question in all this excitement.

So interesting. So syncing environments being the highest metric there doesn't surprise me at all.

Consistently when we've asked this question on surveys, whether it's in a webinar like this or our much larger state of Salesforce DevOps survey that we do each year, It's recurring theme. I think syncing environments is hard.

I think there's a lot of considerations, especially if you've got multiple work streams going on with multiple teams.

But I think, again, this comes back to just kind of designing your life cycle and your process a little.

Whilst it's possible to back port changes from higher environments back down and avoiding the need for refreshing sandboxes, especially if you've got work in flight, You know, I think if you can kind of get a, you know, sort of team cultural alignment to, you know, this is the way that we move changes through environment step by step by step.

I think the need for syncing environments will reduce. Now there's always a corner case with anything like that and there's going to be things like the need for hot fixes where there's in flight development of new changes but then the support team will get a call from an end user and say 'Such and such isn't working, we need this fixing, we've got to get this report out today' etc.

And you just sometimes just have to jump in and solve the problem but then you're stuck with, how do I make sure I don't lose that change with subsequent deployments? And that's where that whole sort of sinking environments back downstream will come in.

If you want to learn a little bit more about some techniques for doing that, you know, we do have our gear set pipelines product and that's a much more sort of graphical view where you can see each of your environments and little lines that connect them and changes that are flowing through that. And one of the things that pipelines does particularly well and supports is what we call back propagation. It's that exact scenario of moving changes backwards down the pipeline. I'll say it's not something that I'd encourage folks to do all the time and if you find yourself doing that all the time, probably want to start revisiting your design of how you deliver changes and see if you can move to a more forward looking model.

But it is possible if you get yourselves in a pickle.

Other than that, shout out to the seven percent that don't have deployment challenges.

You're either completely smashing it or someone else is doing your deployments.

You know, we are DevOps people and there's still challenges. You know, they're going to happen that The quirks of the platform and changes between releases means that we have to adapt our product as much as you, you know, the Salesforce community have to adapt as well. So I am quite surprised of the number of folks that are not hitting those challenges.

Yeah, really interesting there.

It's surprised that a third of people are successful less than fifty percent of the time, so I think that at least some of the strategies that you've shared today will be able to help, and we would really encourage people to take advantage of the free trial of Gearset as well. Think at last camp, we're sitting at ninety four percent success rate for deployments, which is right up in that top third. So hopefully we can help a few more people get there.

Yeah. One more tip I might actually throw in quickly, just kind of keeping an eye on time.

Another quick win to start getting into that a hundred percent category is smaller releases. So, if you've got a release where you only need to add or change a couple of fields and a page layout, just get it out the door, don't wait for packaging it up with a larger sprint because the more changes you've got in the deployment, the more things that can go wrong. If you're deploying often in smaller chunks, then A, you're getting changes into the hands of your end users faster, which keeps them happy. And B, if you're just doing like a couple of field changes in a page layout, the chances of that deploying first time, far greater. And then you're going to start getting into your one hundred percent territory. So yeah, small pieces, little and often.

You took the next question out of my mouth, which was, I was going to ask you if there was one thing that we could do to have a fairly instant impact on our success rate, what would it be?

But it sounds like smaller releases would Yeah, that you'll start doing and you know grow your confidence, it'll improve morale if you are particularly beaten down by unsuccessful deployments.

So the less than fifty percent folks on that statistic, know, let's make their lives better. Let's get some little quick wins out for them and, you know, and grow on that.

Brilliant stuff. I think we are just about coming up to quarter two of the hour, so I think that's probably all the questions that we've got time for.

So I'll let you wrap up and then we can let everybody, especially in the US, get on with their days.

Absolutely. No, I think there's been some great questions coming out there and some interesting stats.

Hopefully the answers have allowed you to reevaluate and think about how can we solve some of these challenges And we look forward to seeing the deployment success rate graph change for the positive next time.

Great. Thank you all so much for joining. We'll be sending out the recording of this webinar, so there's lots of information there, but I'm sure you'll want to rewatch it. And, of course, if you've got any additional questions, then you can always reach out to our friendly support team, and they'll be happy to answer those or feel free to reach out to us and of course come to DevOps Launchpad to further your knowledge in DevOps.

So thank you all so much and I hope you have a great rest of the day.

Thanks, everyone. Take care.