Salesforce DevOps 3.0 is Here - Are You Ready?

Transcript

Hello, everyone, and welcome to another Salesforce Ben LinkedIn live. This time we've collaborated with Opsera to bring you the latest information on DevOps 2.0. Whilst DevOps is still quite new to Salesforce admins and developers, There's been a few developments over the past several years. And the real question is, are you ready? So before we get kick things kicked off, let me know in the comments where you're joining from today. I'd love to see where everyone's from. A few house rules to go over, this is a LinkedIn live it will be recorded and it will be available on our LinkedIn and our YouTube.

All lines will be muted, but don't worry. The comment section is open. So feel free to chat. And ask questions through there.

Perfect. So I'm delighted to introduce you to Kumar. Hi, Kumar.

Thank you. Thank you. The Salesforce Bend team and, for for your support and, given the opportunity and to share some thought leadership with the community, and then we also want to learn from the communities, see where they are, but glad to have the opportunity to associate with you guys and share some knowledge and experience that we are seeing in the industry. Thank you very much.

Should be great. Well, I'll hand it over to you now, and I'll see you at the end for the q&a. Thank you. I'm just gonna go to the deck right away before I get to it.
And thank you, everyone. Good morning. Good evening. Good afternoon depends on where you are. I know the multiple time zones.

I'm Kumar Chivukula, co-founder and CEO of Opsera. Today, we are here to talk about what is the evolution of Salesforce DevOps? And, we are coining the term as DevOps 3.0. I will explain what it is and what's the journey looks like and what is the what are the pros and cons in each of them and how to what are the benefits? Maturity model, and then how do we how do we what are the takeaways from the conversation?

So I just introduced, but I'll also introduce Opsera first, we are the unified DevOps platform where our goal and vision is to enable and power enterprise companies and developers to make the software delivery faster, better, more secure. That could be any software, SaaS, SDLC in Verizon code, and, provide end-to-end visibility as well.

Without any further due, I'm just gonna touch upon the few topics. Feel free to post any questions that you may have. Happy to take them. And, as part of the conversation, keep it interactive, and, we want to hear your feedback as well.So first and foremost thing is the agenda. We would we we thought about it, and how do we, like, explain this whole thing in general what what's happening in the industry?

Doing the brainstorm, I have to start from the definition of DevOps, but most of you know the definition, I'm not gonna bore you down with it. And then how the Salesforce adopted the DevOps practices and how the evolution happen, what are the key benefits of this, DevOps 3.0 maturity model as well.

What is DevOps? Like, I believe that most of you know in case you don't know, and this is not the definition I made up, it this is from AWS, bunch of others, also Salesforceben.com. We took the picture from there. It's a it's a culture and it's philosophy and as well as its practice and the collection of tools, combination of all of them.

They need to come together to help enterprises and the developers to shorten the development life cycle and the provider continuous delivery with highest software quality and security. That is the genesis we end up with, the software delivery was there when the software really came into the market, the mainframe, and as well as, client server, now the cloud and architecture it's there, but the form of the delivery has changed significantly with the cloud and SaaS applications. And that's where the DevOps is taken into a different level, different orbit altogether. It's very prevalent, and it's something that's very commonly used in the companies.

And most of the enterprise companies are aware of this DevOps - there are dedicated teams as well. So the idea is: you build something, you ship, you try to go through your pipelines and delivery pipelines, you ship it to the customers faster, better secure, and also have a feedback loop mechanism to ensure that what you're delivering is working and also it's it's helping the enterprise helping the consumers or enterprises to achieve their own goals as well.

That's a definition and a simple easy. Let's take a next step, right, in the context of the DevOps. What is it for Salesforce? How Salesforce fits into the DevOps? So as you can see, the concepts are thesame, but how do you overlay the DevOps concepts into Salesforce?

Salesforce is a platform. It's a SaaS platform. It's done differently, but Salesforce grew significantly in the last fifteen, twenty years. Where it be more than just one platform, and it has so many modules started with CRM. Now that they have many aspects that I added service cloud support cloud, data cloud, and you name it. They also added other companies as well. Right? You have a Tableau, Slack, MuleSoft.

They continue to acquire a bunch of other companies. It's not easy for them to do the development, the way they've done it, the way they design an architecture in the first place. But at the core of the Salesforce, there are few stages inside the Salesforce DevOps. Then you you need to have some kind of a source code management where you want to have to keep your your packages, metadata, your profiles permission so that you can coordinate with multiple developers, multiple engineers within the company.

And when you have the source code and you have a sandbox, Salesforce sandbox, you interact with sandbox and source code a lot. And what the reason being is you want to ensure that your stories and your, your activities have been performed and before you push them to the higher level environments. When you're ready to push your core and integrate them, that's where the your package dot XML and where you go to the integration test full unit testing and then your code scanning to make sure that you don't have any known vulnerabilities and no issues have been addressed. And then you deploy them before it do the functional testing.

And before you deploy them, we have an opportunity to have a way to protect yourself with with some kind of resiliency with backup so that you have a in case of an event of failure, you can restore your metadata and change management and the IDSM so that you can have audit and audit trail. All these things are important because especially when enterprise company, when you have a more than ten to fifteen developers, it tends to be very challenging to manage the overall Salesforce DevOps functions, which is what we've seen at many companies and you need to have a process and platform and be in a position to manage these things as opposed to continue to do the resources and, it is not scalable model.

It impacts your go to market. It impacts your agility velocity. It impacts your shift left automation of security quality posture. It also impacts the overall governance and you don't wanna be caught in between when there's an audit issue, when there's security issue and a quality issue. It is those things that have become so expensive for you and also take away your focus from doing the things that matter for the company. So these are the stages and by no means, we are saying that this is completely fixed. There are ways you can make more adjustments. We can talk about it as course of the next few slides.

And, in the sense, we still bring in the the core concepts of CICD and then DevOps concept to the mix, like how do you integrate with the continuous integration, continuous development, and continuous deployment, and using the shift left automation, along with the checks and balances and guardrails that you can use. How do you manage all of them into one common place? And also is there any way you can extend the platform beyond Salesforce because Salesforce is not no longer a sim one cloud or one application. The collection of applications, they're not all built on Salesforce as well.

So now, I'm just gonna introduce 1.0. The three phases we're going to introduce and, keep it simple to you guys. 1.0, 2.0, 3.0. Just bear with me for the next five minutes.

I'll be able to unpack, and we're happy to have a conversation followed by that. So when Salesforce came in, people were struggling to introduce manual deployments and Salesforce came up with the change sets. Most of you know, change sets is a native tool that was developed by Salesforce. It's standard, we're calling it 1.0.

It you can use CI 1.0. Sorry, Salesforce 1.0 change sets to make some changes. It works well when you are one or two developers, when you don't have many changes, maybe, you can manage with one or two or one or two, like, environments. It is still manageable with a smaller team, but it's not elegant. You will not get the governance. You don't get the shift left automation. It's very error prone and also you can also do code overwrites.

And you have to track this manually. Do you really want to kill yourself on the day and age that we are living in the cloud and digitization and doing this work for fifteen, sixteen hours where you can do it in less than five minutes and, less than few of ten to ten minutes where you can free up your time, focus on a valuable aspect, whether when other priorities are your personal time. Right? You don't want to spend the time just focusing on doing the things that can be automated can be managed effectively, and you can also improve, upscale yourself as well.

And it's very cumbersome. Okay. We talked to some of the key differences. I'll just call it out the way it is.

Manual deployments, as you know, take time they're error-prone because when you do the such a manual way of doing it, especially the ecosystem complex ecosystem and Salesforce, you tend to make mistakes because it's possible that it can be perfect in every aspect of it. Right? And you have to track these things from the audit and complaints aspect. It is very hard to pull the information and share it with them.

Not only for audited complaints. If something goes wrong, how do you even backtrack yourself? And then potential code over. Right?

Happens all the time because when you have a more than three four developers, you have to coordinate together between them. And how do you do that? And it's also not easy to differences between some of the components, especially when you have when you want to make a change to Apex class versus, the you you have a custom object versus something else? How do you ensure that who is working and what?

And how do you ensure that you're not stopping another person changes and releases? And dependence is very hard to see it because you select a component. How do you ensure that you have dependencies also there? The last but not least, integration to your your commonly used tools today because especially with remote work that is are in an hybrid environment, your Slack, Microsoft Teams, Jira, ServiceNow, quality security tools, it becomes a challenge and you don't have a way to integrate and how do you communicate? You don't want to cut and paste bunch of these things. You need to have a native integration to these things. To enable your team and enable yourself to have effective releases.

That's the that's where it was started and some of the things that we see and we hear from the people. It's cumbersome, challenge, very difficult. People want to move away, but we still see people using change sets. If you still don't change sets, don't worry about it, we help the people to migrate away from change sets. We can also explain that how we can we enable them to move away from change sets and custom solutions as well.

So the the second piece I hear all the time, like, oh, I have a Jenkins and I've put together people are very proud about it. There's nothing wrong with it. As long as you know, you have a staff and you have a bunch of resources and people are okay with poor experience and people are okay with relying on one person to do everything. Totally fine. You're as good as the person who built the pipelines. Jenkins is a great tool.

We love it, but at the same time, you can't use the same tool for every function that is available. Right? You can do it, but it is not a fit for function in this case. It's not purpose built for Salesforce. When you don't have purpose-built tool for Salesforce, you run into severe limitations we talked about earlier. Like conflicts and, especially with developers, it's a challenge and metadata backups and recoveries, hold backs. It's gonna be a nightmare for you.

And deployment dependency, you can do that, but you you have to write a Jenkins file, Google file, shared library bunch of other things. It has Jenkins comes with the plugins, you have to manage the plugin. Something goes wrong, you pull your hair, and then you are approvals and gates, and it's something you have to custom develop yourself. And then you don't get the insights.

And more importantly, Salesforce developers, which we interact. They are good at what they do inside the Salesforce. Now, we have to find a way to come out of it. Learn how to write the code. You have to manage the things like groovy file, groovy scripts, and Jenkins file, or share libraries. It's not a scalable solution. It requires a lot of resources to manage it. We've seen a couple of customers where the some third party vendor came and built it. And I just spent hundreds and thousands of dollars when they were there.

They had a situation where it was failing and that there was no one to dissolve it. We can't pay another hundreds or thousands of dollars to engage the vendor to fix it. And, it's not easy. Like, once you build it in there, it's running, It's okay, but when it fails, you have no idea how to solve it.

That's the situation we don't want any enterprises or developers to have be in the first place.

Now there's an improvement that happen in the industry. The industry recognized few years back, four, five years back, and then plethora of solutions came in. And, I'm going to call as a black box solutions. No offense there, but I'll explain why black box solution is. Because it is just developed for the Salesforce, but also with the limitations because you're force feeding the people to use where you design your solution, which is not a right thing for enterprises because They already made investment in the source code, investment in third party vendor, third party tools, and also teams have standards in governance and architecture.

You don't want to force with them into Blackbox solution. It'll work, but you're isolating the Salesforce from the overall DevOps ecosystem. And you're also stifling them from innovation to do some things that they can do with other other ecosystem that they already built by the enterprise companies. You don't want to make it as a Salesforce DevOps as a special thing and leave it there as well. It is special, but it can be integrated with the overall DevOps system.
‍
You need to give the choice and flexibility for the enterprise customers so that they're not in the vendor lock in situation. And it's very cumbersome. You have to train a separate team, separate resource team that they have to manage. You can't leverage the same practices that have been designed for overall DevOps. And then you will not get the efficiencies. You have to pay extra money, OpEx, challenges, and you have a separate team managing it, and you have to continue to manage the talent and upskilling as well. And then the day and age of generative AI, plus all the automation that is coming in you need to think about long and hard and see how do you adopt the source driven development, source driven deployment because you need to make your sync source code as a single source of truth.

You want to scale your team and want to manage it. And you want to use it beyond the Salesforce or multiple clouds in Salesforce, multiple SaaS applications, Yeah. Good luck with it. It's very hard to use it with with current solution that you guys have.

And these are the things we recognize. I'm not trying to just these are the things we hear from the customers when we interact with them. They want to have a native integration. This third party vendors like whether it be selenium, whether it be code scanning or it's a sonar queue. Check marks or your cause, ProVark, ITSM tools like Jira, ServiceNow, or collaboration tools like Slack and Microsoft teams, you don't have to pay extra money to have this. These are the things that commonly use DevOps practices, testing, security, collaboration ideas, you expect these things to be there inside the ecosystem inside the platform.

And you want to ensure that you're delivering with security tools as well. And also, by without compromising the speed, how do you protect your agility and also security and be able to have a governance and, put things in features and customer hands faster and better and secure as well.So in doing so, how do you get the overall visibility and governance? Right now, DevOps, zero solutions, They give some visibility, but it's, again, it's in their own way of doing it. Dora metrics and, which is very much Google talks about a dev ops with Dora. They go hand in hand for the most part in terms of how you can measure your velocity, stability, reliability, agility, and whatnot the way the four famous total metrics that you have change failure rate and, your mttr and, your lead time and the deployment frequency.

Those are these are the four important key items. You can talk about it. Like, I I don't want to just put it on with just a tangential way, but I want to give you the thirty seconds overview why these things are important. How do you ensure that the the changes you're making are stable and resilient and also improving your productivity and also improving your customer experience? You have to have somewhere to measure that. DORA metrics is one indicator. I'm not saying that that's the only way. And having the DORA metrics will help you achieve your better outcome in improving the building the high performance teams.

And, you need to have this not only do our metrics, developer productivity metrics, security posture, if within the Salesforce ecosystem, you need to be in a position to try, trace it back to the commit to the core, your, your component that you released and how do you ensure that you backtracking changes and, and understand which test class used and whether this change went through the proper validation testing. You got to have a way to understand and where the bottlenecks with the challenges. So Visibilities and governance are paramount and especially in the ecosystem that is so complex now.

With multiple applications, multiple clouds, and dispersed. We have a teams that are distributed across various geolocation, various regions as well. So that's about history, 2.0.

Prominently, the way most of the enterprises are here and, you continue to see some shifting differently, but most of them is seventy to eighty percent of DevOps 2.0 based on what we see. In case you guys have any feedback or so, like, let us know. And if you're, you have a if you're 1.0, 2.0, looked, happy to get some feedback from the as part of the discussion as well.

Now, the Salesforce DevOps 3.0, this is something that we're we see not only us Gartner and as well as industry and, they're talking about it. So there is a new term, and we used to call value stream management, value stream delivery. The DevOps thing, but now they're calling us a DevOps in the platform. We've been preaching it for the last three years. And, you're having unified DevOps platform by without compromising the autonomy and choice and flexibility. You want to have Salesforce team to have their own Salesforce DevOps ecosystem, but still be able to leverage the DevOps practices. Same thing with respect to MuleSoft or maybe you are Snowflake informatica or is DLC application with Java dot net Python. How do you give that in a hub-spoke model where you can have a federated way of doing it and but still be able to get the governance visibility, feedback loop mechanism automation along with your your way of driving your own car at your own speed.

Right? So you don't want to be stopped in between. So having a unified DevOps platform is absolutely critical for to achieve that. And, you can get the standards and governance visibility feedback to mechanism automation. And by doing so, you can also have a way to integrate with security quality tools with thresholds and gates and having the seamless integration. You don't have to think about after the fact. You want to make sure that you need to have a legal blocks, legal books. So what we what I mean by legal blocks and legal books, you need to be in a position to concept your pipelines and concept the way you do things, you need to have some kind of templates and so that you can use it as a reference and build your own templates, or you can build the way you want based on the standards that you have.
‍
Let's say, for example, you have a particular security tool. You wanna integrate the Microsoft Teams or Slack. Some will have Jira. Someone has maybe you have Jira for story management and and ServiceNow for your change management. How do you bring all of them in a plug and play fashion?

So you got to have that kind of flexibility. That is the ecosystem we are talking about when we say DevOps 3.0. So now I'm gonna just go into the little deeper into it.

So first and foremost thing is you you you need to have a source driven development, source driven deployment. What do you mean by source driven development, source driven deployment? What not just officer or engine industry. The source is like where do you keep the source? More more often than not people use their sources, sandbox environment, but we need to bring your changes to the GitHub, GitHub, Bitbucket. Any of the source code management tools are prominently used, which are adopted in the DevOps ecosystem.

You need to use that and create your own branching strategy and be in a position to use it. It it may sound cumbersome, but once you adopt that, agility, resilience is much greater for you. And you have you can scale from ten developers to hundred developers, hundred to three hundred developers. You've seen a few of our customers adopting and adopted source driven development and source driven deployment and scale and more to improve their overall agility velocity. And also improve their overall, the release, release increase the number of releases and number of components that are deployed.

Your happy developers, happy happy business users as well. And then, you need to give the flexibility for them. The second part is gotta give the flexibility. Once you have a source driven development, source driven deployment is already adopted, how do you ensure that flexible deployment?

So you can move from our deployment get to get and get to get. How do you give these options inside that? We talked about plug and play. You want to be in a position to connect to your ecosystem. You don't want to be left behind just because you're running a Salesforce DevOps 2.0 and are in a black box solution. You need to be in a position where you can take advantage of what is happening in the industry and how do you stay ahead of the game and also innovate yourself. Right? You gotta make sure that you manage that.

And you need to be in a position to extend because when Salesforce is the team is not just managing Salesforce. You you will manage beyond Salesforce in some cases. You don't have a fifteen different solutions lying around. One for Bumi, one for APG, one for Snaplogic, one for Snowflake, one for Informatica, one for STLC.

You want to be in a position to bring it together, be able to leverage it without compromising the independence as well. I touched upon it, creative integrations, having your native integrations to the security, like whether it be not queue, check marks, or, your, your code scan, or a PMD or code analyzer, quality tools, selenium pro, and, any other field for unit testing validation and ITSM, that's Jira, ServiceNow, collaboration, Microsoft teams, and Slack. You have you need to be in a position to plug and play, connect to them. How do you bring these lego blocks in the ecosystem without thinking about it should not be after the fact.

Having end to end visibility in in the overall ecosystem. One is to deployment and deployment stats is one thing. DORA metrics is our secondary thing. Is that the second thing? Third one is you need to have a how many developers are working, how many engineers are there, how many release managers, how many releases completed last month, whether the releases complete, whether the release that is that the completed last month went through this proper security quality gates. Do we have a proper approvals? Do you have a proper way of auditing and go go back and look at the things how many components are deployed. You want to be in a position to crack to the level so that your life becomes easier. You don't have to scramble. And when there's something doesn't work and something you have to go back and track it. For the you want to be in a position to confidently go there and deploy, right?

So you need to have a back if you have a backup and recovery, you don't have to worry about it. Okay. If something goes wrong and because some some change happened and they went through all the stages, but still even if you put all the guardrails, sometimes people make mistakes and things will fall to the cracks. This is one another way to protect yourself, having a backup and recovery before you do anything.

Take a backup ensure that you have a way to recover yourself in a fast way quickly so that you don't have to spend a lot of time and post release and scrambling yourself to find the way to recover use recover the the good loan state.We touched upon auditing complaints extensively the culmination of that, which is because of the DevOps 3.0, where you need to be in a position to have the choice and flexibility, source development, having the end to end visibility, automation, feedback with mechanism, be in a position to be stay in the ecosystem of DevOps as opposed to outside the DevOps and calling as a DevOps, but it doesn't work that way because you cannot able to mature yourself. Move the needle and be not able to achieve the outcomes that you have. So I want we want to I want to touch up on some of the benefits of why you should be looking in this thing. Right?

So when you look at the key benefits of Salesforce 3.0, I'm gonna uplift the conversation from technology features to the business benefits. Right? Your scalability resilience is paramount for many companies. And, especially with digital transformation, when you have a multiple developers, multiple environments, multiple projects going in simultaneously, how do you scale, how do you improve the resiliency?

The second is agility, agility allows a time to market in doing so when you are scaling should not come in the way of you being going faster, right, time to market agility. How do you find more the features faster and be able to address the needs of the customers, also your business users as well. In doing so, you don't wanna compromise your security. How do you ensure quality as well?

How do you ensure your issue using shift of automation? Be able to automate your security quality and improve your posture so that you can understand and identify the identify detect and protect your good known vulnerabilities, known issues from the source code. Are you con with components and the packages? Anything related to the the your Apex class or JavaScript to any of them that you have, you need to be in a position to catch them, fix them so that anything you do a post goal life and when we detect issues and security, it becomes costly exercise.

Gartner and IBM have done the research, couple of years back. It talk it takes about six to fifteen x times effort and energy and resources and cost to fix the issue post production versus if we catch the issue, you can avoid and save that much time in the first place. Governance, we talked about governance and why governance is, critically important. And, if you look at the the now impact each of the areas, right? These are the business benefits and key benefits for the company. And, talked about source level development and which will help you scale and across multiple developers, multiple projects, multiple stories. And you don't have to worry about it. You can have feature brands and you can have a project branch, integration branch, your hotfix branch, and you have various other things having a proper branching structure.

It'll help you scale yourself as well. You need to be in a position to scale yourself by having a platform that supports SaaS applications as SDLC have unified DevOps because you will take advantage of the overall DevOps ecosystem as well. And you need to be in a position to support parallel releases as well. You need to be in a position. Okay. Do you want to just shut down everything. We have seen a customer and and I want to make a release and I want to freeze entire thing for two weeks. You don't want to do and the you're blocking innovation, blocking the ability to move faster, and having a rollback capability, which will there is a resiliency aspect.Resiliency is twofold. One is with people resiliency and the platform resiliency.

That's about scalability resilience. And, when it comes to agility, You want to have, lock the release branches so that people don't have to win and make sure that you put the mandate code reviews and get it approval so that you can in improve the quality of the core and in every step of the way. Why it is important? Because you can the more you improve the quality of the lower level environment, when you go to the higher level environments, failures are less and faster releases, and you don't have to you can seamlessly push the components through automation.Otherwise, you even if you put automation, quality is not there, you suffer multiple outages, multiple issues. You don't want to do that. Integrate with your tools that we talked about it. And, having the backup and recovery, again, agility comes along the way.

One is resiliency. You can quickly recover restore and move on.And then third one is which we talked about shift left automation. And, you need to have the code level at the when you're doing the checking the code also, when you move into the code, the various environments, having the various gated approvals. And, you can detect the issues and put the thresholds in such a way. You can mature into it. Now, you don't have to achieve the hundred percent security quality posture.

It's a journey. It's not like one time even in the shift left automation, this bucket. It's don't think that you just do it once and forget about it. You can code is gonna change.And then, whatever it is are gonna change. Your new bugs and new issues are gonna pop up. You need to be in a position to, have a way to connect all of them. So when you connect to the third party vendor, third party tools like PMD, on our cube selenium robot, you it should be seamless, and it should not be like writing bunch of code.It should be plug and play. And you need to be in a position to put the thresholds and alerts notification. You can mature yourself. You can have a maturity model of crawl, walk, run, to the point, and where you can, make modifications.

You can improve them or on maturity from where you are. You can start with thirty percent security pass or maybe forty percent development. Maybe when you go to quality QA environment, you can improve the fifty percent. When you go to UAT, can improve eighty percent.When you go to production, ninety percent. So that you can improve the gates in such a way based on the environment based on the business rules, policy, you can ensure that your team is achieving that and they want them incentivize them as well. Don't try to just focus on technology. It's part of the culture and don't call them as a don't don't look for people, when there's an issue and try to fix the process and incentivize them, motivate them and embrace the change in culture, then you will get the benefits of that.When you do the governance, those are the things you have to keep in mind. Having the proper granular level of role based access, release manager having the proper access, what's the Salesforce, DevOps admin. So DevOps engineer, what's the Salesforce admin? And or you have manager, you can def define these rules and we know in a way where they don't step on each of the functions.

Download will be spending mostly on the lower end one. And the release manager will be taking from the QA on what's every, to the higher level environment. Salesforce admin, we have production access. And how do you ensure that you're not you're you continue to protect the role granular role based access segregation of duties, but still be able to move through the chains as well. And having the visibility and then there are ceiling. You know, how do you refresh once you complete the change, how do you bring the good known state of the production copy to the sandbox so that you don't have to struggle with it. Those are the key benefits of Salesforce DevOps 3.0. So, interest of time, I'm just gonna cover the maturity level quickly. And then, talk about the Opsera and then open for questions as well.

So why this is important? Not everything has to go into the final stage all the time. DevOps maturity model is absolutely, like, if there's not, you don't have to follow this guidelines, all by yourself. You can start where you are and walking the journey. Sometimes, you can, I'm sure, like, maybe in the crawl and walk, but some of you in work and done, some of you, maybe in a few of you, few companies maybe in a flight state, not end to end, but we've seen couple couple of them. But but you you can start with your own piece. You don't have to run to the good run stage sometimes it's not required in all the all the scenarios, but at least be in a run state with the maturity model for it to to to unlock your potential, unlock your benefits, but run to fly, take some time.

We'll talk about it. How does the maturity model look like? In the crawl state,  it's mostly 1.0. To be honest with you, like 1.0, pre dated 1.0. In the, If you look at the walk, it's you have some automation. Like, maybe dabbling between 1.0 change sets and try to do with some Jenkins and whatnot. And you maybe walk and run state where you have some custom solution, a black box solution that you have for you to go from consistently in data run onto the fly, you have to embrace the platform and 3.0, the 3.0 concepts we talked about it to achieve the the value that we are articulating in this, examples and various scenarios as well. So I'll just quickly cover that. Right? I

n the crawl state, we're talking about most mostly doing the manual. We are doing in the walk stage, you have some kind of version control system, you have Jira, some automation, some integrations, like, but it's not fully there in terms of where you can speed things up with security quality governance. And then when you run when you enter a run state, that means you have a mature team. You have so you adopted the source seven development, source seven deployment. You started putting the gates and quality gates and security gates and you have a rollback mechanism. You have a static code analysis and reusable templates. But when you go to fly, that's where you have to go to the higher level, you are quantifying the benefits to the business and you have a single pane of glass to monitor these workloads and ensure that you can have predictive and actionable insights because you will be able to understand when something goes wrong instead of calling and opening a ticket, you a position understand why this validation failed, why this unit has failed, why this component didn't go, why this deployment failed. You should be able to understand those issues faster and be able to remediate them. And we touched upon DORA metrics as well, measure with them and then understand the stability and understand the agility velocity. And the resiliency. How do you ensure that you make smart decisions with the metrics that you have?

And when you hire, you go on the maturity, the strategic value of the company goes up you will be able to articulate the value to your business, your management teams as well. And these slides will be available, and, we will share the information. We have a any interrupt, if you want to double click this one information, we're happy to talk to you as well. So allow me to introduce Opsera's Salesforce 3.0, and how we talk we approach it as well. Right? We talked about all of all these components and whatnot.

Opsera is designed for these capabilities and we are a unified DevOps Platform. Our goal is to enable and power enterprise companies to manage the releases, any software, any software, any cloud. And, that can work in the context of Salesforce, we give you the core capabilities of DevOps 3.0 plus more as well. So first and foremost, when we talked about flexible deployment options, you have a way to use your, source driven development. In some cases, you can also have off to off deployments and, in some lower environments, but you can also have a get much conflict, native get much conflicts, and be in a position where you can seamlessly scale your teams as well.

Out of the box integration, we talked about all of them. You don't have to look at them, pay, say, pay this. Separately, they come as part of the platform. You can easily plug and play, and that's what we call as lego blocks. And then you have a continuous visibility includes and dashboards and powered by Hummingbird AI, which we just released yesterday, and not only get the visibility, and you also have a way to understand and remediate and, resolve issues faster with predictive, we are doing it.

And the complaints and governance, and, we talked about it having a granular rollback mechanism having the blueprint for audit and logs and the standard templates which are these are the lego groups for you. And with approval gates, you don't have to reinvent the wheel right in the custom code and for engaging third party vendor with integrations.

They come out of the box. You can have a proper alerts and notifications with your Slack and your Jira email. Google chat, whatever you have, and, you can use it to send alerts notification page at UT, whatnot. You can get the alerts as well.And then last but not least, data ceiling, data, data backup and recovery platform offers these things as part of the, and, you will be able to full take full advantage of the platform and be able to scale scale faster and do more things with the do more do more with less. And then you can deliver the better software.

And also you can significantly reduce the toil and then have make make the team as a happy developers and have happy Salesforce admins and the release managers as well.So we are not just for Salesforce releases. We can speed releases across other SaaS applications as well. And one device platform, they can cover it all, and without compromise in the your depth and breadth as well. Okay. Horizontal vertical, we can go deep and wider as well.

So how can you sign up? And you can sign up to the Opsera, sign up for Salesforce DevOps 3.0, go to opsera.io and sign up to the demo or maybe sign up for your, a trial free trial or, with what we can offer. And then we can have a conversation. That that concludes the session. Thank you very much. Thank you, Kumar. Such an insightful session, I definitely understand more about DevOps in general and DevOps 3.0..