Description
Keynote session recording from the Gearset DevOps Summit, October 2021.
Join Andrew Fawcett (VP of Product Management for Salesforce’s Platform team) and Kevin Boyle, (CEO and Co-Founder of Gearset) as they shine a spotlight on the three essential pieces of the DevOps puzzle: people, tools, and processes. Find out how to encompass these key drivers in an effective DevOps strategy to ensure your team’s success!
Learn more:
Transcript
Really excited to be here this morning, and I'm really hoping I'm engaging enough to keep the folks in Australia, happy that they stayed up to two AM. So thank you very much for joining us, wherever you're joining us from in the world, but I'm gonna I'm gonna work extra hard for anyone that's staying up late.
Good morning, everyone, and welcome to the keynote of our DevOps Summit.
Today, we're gonna be talking about piecing together the DevOps puzzle.
I'm Kevin, and I'm the CEO here at Gearset. I'm a software engineer by background and help build out the platform that underpins Gearset.
These days, they don't let me write much code anymore, and I instead, I have the pleasure of spending the vast majority of my day and week speaking to our customers about how to effectively use DevOps within their teams and organizations to get the most from their investment in Salesforce.
It's a real treat for me today to be doing our keynote with one of my absolute favorite people in the Salesforce ecosystem, Somebody that has been at the forefront of DevOps from before. That was a word that we were all using and building big, well architected solutions atop the platform. Andy.
Thank you very much, Kevin. I'm really honored and, stoked to be here with everyone and, looking forward to the session. And, what an amazing lineup of great speakers and sessions you've got, today. So, congratulations on kicking off the keynote, and happy to be part of it. Thank you so much for the invite.
Thank you.
Awesome.
Before we get stuck into the topic, I wanted to reflect a little on the sort of why you have DevOps.
It's kind of a grandiose term, and it can mean a bunch of different things to different people. And I think it's important to go back to basics and and think about what problems the DevOps movement is is actually tackling within our teams. At GearSat, you know, we can see the impact. We can see the teams that have a smooth DevOps process, have higher rates of innovation, and can deliver results to the business more quickly. But what are some of the key challenges within their team that, you know, they're actually solving?
As I said, DevOps has many different definitions depending on who you ask. Originally, DevOps was a way of working that brought together development teams and operations teams to remove bottlenecks and silos that were slowing down the process of getting great new work that had, you know, been built into the hands of end users.
DevOps isn't any one thing. It's it's a combination of the culture of your team, the processes by which you build and release your software, and then the tools that you use to support that process.
Your DevOps strategy will define how your team works together to build software and and get it into the hands of your end users.
Due to its nature, a great DevOps strategy will will necessarily vary, depending on the platform that you're building on. Different platforms have different sets of needs, different sets of constraints, and Salesforce, you know, frankly, takes away a bunch of the problems we'd face on on more traditional platforms.
And there's much less of a need for that sort of classic operations team, you know, on the whole compared with, say, building on Google Cloud, AWS, or Azure.
For teams building on Salesforce, most of the challenges that DevOps helps to address is actually around collaboration.
It's a really key topic that's often overlooked, But building software is a team sport and your DevOps strategy needs to reflect that. Everyone has to be able to take part.
Great DevOps will allow declarative and programmatic folk to build on each other's work without overriding changes and help to come to help to overcome some of those team silos that can form.
With a robust DevOps strategy, you'll have predictability in your delivery pipeline, and that that's really what it's all about. If you've got a well understood process and have confidence in it, then you can predict how long it's going to take to release. So when you kick off a new feature or change request, you understand what a delivery date might look like.
Great DevOps will also foster a more agile and iterative way of working where small changes are continuously built, tested, and shipped.
By continuously delivering new functionality, teams can rapidly receive and incorporate stakeholder feedback resulting in higher quality releases that are more closely aligned to the business goals.
So over to Andy to talk about how we make great DevOps happen.
Thanks, Kevin. And as someone just mentioned in the, in the chat that software development absolutely is a team sport, and, that really teases up for the kind of next part of the discussion here.
There are many benefits, to DevOps for a business. What we would focus on today is how to put DevOps and the way that your teams build the experiences into practice in your organization.
So we want to focus on three key components of success for that, people, tools, and processes.
Now if a good DX if if a good DevOps, situation was a puzzle, then the people, the processes, and the development tools are all there to make things things slap together successfully.
Now whatever your business specific industry is or team setup, these pieces will make or break your DevOps strategy.
Your people are fundamental to that strategy.
They're the ones that make a great DevOps happen by operating your tech stack and working with the business to ensure that you're staying on track and your broader goals. Ultimately, they're the ones that collectively press that deploy button.
Your tools either unblock or complicate the process of building and delivering the solution to your end users.
Right? You need tools that and platform capabilities that optimize your team's ability to build efficiently.
Those that are compatible with your team's skill level and make the release process even more visible for everyone.
And finally, you have process.
The process is not just a set of features. It's the framework in which your tools and your teams operate and defines how they work together to release these changes.
So in this talk, we'll be talking about the three these three components and how you can optimize your DevOp and build strategies to help all three of these work together.
Now when we think about a team to deliver a new experience to your users, we often think about staffing with just developers.
Now developers typically interact with business domain experts to understand the requirements to deliver the solution.
Well, that's certainly a valid model, but there's a more rewarding and effective way to leverage the desire in all of us to be creative.
So in this section, I want to explore ways in which we can create a fusion of skilled individuals that can programmatically or declaratively build together.
Such teams are more collaborative, have more fun, and drive to better outcomes, especially when they're seeded with business domain experts that know the end user or even one of the intended end users themselves.
The first step in uniting people to build together is understanding what features the platform enable enables to be able to bring and leverage a mixture of programmatic and direct clarity skills together to build this overall experience.
What continues to get me excited about the platform is how developers can give declarative builders superpowers by leveraging increasingly deep extensibility within the platform's various builders, such as app builder, flow builder, experience, and bot builder.
So let's start with custom metadata.
It's a great starting point to capture the business metadata, such as business related codes, regional, or departmental based variances that can be directly referenced by the builder tools and for and formulas all still without code.
Now while Apex can be used to drive complex standalone requirements, it can also be used to create reusable actions that can be exposed in many of the builders we just mentioned and with only a simple few annotations.
Did you know, for example, that you can extend the flow building UI itself with your own lightning components?
Developers can then make more complex Apex actions available with dynamic UA prompts, validations, just like the standard Salesforce flow actions.
It's amazing feature.
The clarity builders can create platform events, and then they can ask their Salesforce developer team members to send those events, and then they can create and enable declarative alerts and further declarative automations.
Now finally, it would be remiss of me not to reference the wider programmatic skill set that's opened up by leveraging Salesforce functions, which I'm super proud of the team at Salesforce to have just released this week.
In addition to open and greater performance and scale, functions enables developers to leverage their skill sets in industry languages and open source libraries while staying on the platform with everything that we've just discussed.
Surely, this is a skills reuse nirvana for any project developer.
Now it can be exciting to get started building something, but don't lose sight of who you're building it for and the aspects of their daily life that you want to impact and change with the solution.
So declaratively building with tools like Flow, standard lightning web components, mocking out programmatic aspects can go a long way in standing up a proof of concept or a demo to get solid feedback on what your target users really would find useful.
The good thing about this is you're already starting the development process when you do this, and you can start to see more easily what part of the architecture looks like what the architecture looks like and what skills mix you're going to need.
At the foundation of a successful team is the ability to pull together when needed yet work independently and come back together in an iterative way and see where that end to end experience is in its maturity.
Now a clear DevOps strategy that considers preview environments on a sprint boundary, for example, is one such way to enable this.
Now if you're doing DevOps and have their own correctly, then you're considering regular communication with other parts of the business, and it's just very critical.
DevOps KPIs are important to help drive process improvement by monitoring defects or team velocity, for example.
Understanding key business APIs that the company wants to see impacted with the experience is also equally important.
Validate your KPIs early with your stakeholders and deeply understand what aspects of your steel thread that we just spoke about impacts those KPIs, validate them.
This can be used with data that you create or identify operational data for which the experience runs them over, and you will report on this, for example, order creation dates, reduction in data errors examples for it, etcetera.
Now features like custom objects, platform events, and even the good old lightning utility bar are all ways to explore ways to implement basic forms of custom KPIs if your operational data isn't always giving you the right, information that you need to monitor those KPIs.
So thank you very much. This is all from me today, but back to you, Kevin, to continue with our wonderful keynote.
Thank you very much, Andy, and congratulations to you and the entire team on Salesforce functions. I think it's just an it's another, bow in in in our arsenal for combining and building these types of solutions that bring declarative developers and programmatic developers together to be greater than anything any of us could do separately. So congrats to you and the team.
Thank you.
As we've just heard, investing in a culture of transparency, accountability, and collaboration is is a fundamental part of a successful DevOps adoption.
But teams also need to work together to deliver those high quality changes they're building quickly.
When choosing the tools and processes that will form part of your DevOps strategy, I think you have to make sure that they're accessible to the people using them. There's no point implementing something that can only be used by half of your team.
Think about the technical knowledge required to use any given tool or process and ask yourself if it's suitable for everyone on your team that's involved in the release process.
Opt for tooling with a straightforward user interface that can be understood by anyone without putting up barriers to adoption.
Intercom are one of my favorite companies. They're they've been with Gearset since the very start. We've we're lots of our, support is built on top of them, and they're one of the best avenues that we have had for staying connected to our own users as we've scaled Gearset.
When their Salesforce team onboarded with us, they had the vision to build an inclusive DevOps process.
They told us from the start that they wanted to make sure they weren't catering to only their programmatic builders and excluding the the clarity of folks. They wanted a tool that would be user friendly for everyone.
Ultimately, your DevOps strategy is only going to succeed if you have full adoption and buy in from your team, and that's your whole team.
According to Puppet Labs, one of the earliest advocates of, you know, what was then a burgeoning DevOps movement, six in ten teams with highly evolved DevOps practices say DevOps is actively promoted within their organization.
You need to invest time to educate your team on how and why to use your decided tools and processes, you know, whatever it might be, and how they fit in with your DevOps goals.
For example, if you're adopting version control, does everyone understand how it would benefit your business? Do they know why that poll request is important?
And training your team is easier if you use tools with shorter ramp up times.
You can help everyone see the benefits quickly so they don't slide back into the old way of doing things when, you know, when you really need to move fast.
And steep learning curves and, avoid steep learning curves and look for a tool that's intuitive and a process that defaults to simplicity wherever that's possible.
If If you wanna build together effectively, you really can't ignore version control. It's it's it's just a game changer for your DevOps strategy, which is why eighty nine percent of the teams, say they currently plan to use or adopt version control according to our twenty twenty one state of Salesforce DevOps report.
Teams working in the same sandbox constantly treading each other's toes and block each other's releases.
And version control solves that problem really effectively.
It allows everyone to develop and customize on separate branches that don't block anybody else's, improvements that are gone simultaneously.
Every member of the team works safely in their own branch and and deals with any potential conflicts well ahead of the release.
Here in the diagram that me and our master branch in Git acts as a source of truth for all new work instead of your production org.
Using Git in this way helps you keep environments in sync and allows you to manage multiple work streams that are flowing through your pipeline.
All the folks building out your change request, be it programmatic or declarative, make changes in their own feature branches, and these changes are then automatically pushed to staging and testing environments as soon as that work has been approved and merged and merged.
Changes are automatically validated against production to make sure they're good to go, and then they can be released at any time.
Learning to use Git to collaborate as a team isn't hard with the right tools that puts everyone on an even playing field.
These tools provide a friendly UI and visualize actions like committing work and opening and merging poll requests.
DevOps not only calls for teams to build together, but also to build better. And I guess it's a bit subjective. So what do I mean by building better?
Better software tends to be robust.
It means that customizations don't break anything and features that can be easily extended in the future.
But even more importantly, we want to build functionality, as Andy said, that is that is driven by our users' needs. Alright? That's that's what we're all doing it for. We need our development and customization work to be well tested and and driven by the precise needs of our end users.
To make user driven development a reality, you need to create a feedback loop by releasing small chunks of work at a time and have that fast turnaround to get their feedback. So then when you get the users to test the customization, you know, they can give you that feedback as soon as you're ready to move on to the next thing. A virtuous cycle is then created where improvements are continually added and tested on a rolling basis.
Here again, we see DevOps made possible by linking people and processes.
DevOps is successful when there is a good relationship between the folks building what the business needs and the rest of the business that is gonna use that work. And as Andy correctly pointed out, in some cases, those are the same people.
When this relationship works, people across the organization come to value and appreciate the work of the Salesforce team as they get hands on with new features that meet their needs on a more regular basis. The Xometry team, who we're gonna hear from later in the summit, have recently put in place just an absolutely great process that prioritizes user feedback and visibility.
They use Atlassian's Jira product, and their Jira board is open to everyone so they can see where their team is in the pipeline.
So once you're delivering better software, you'll then wanna speed up your releases and and tighten those feedback cycles, and automation is key for this.
Repetitive manual tasks are prime candidates for automation.
Continuous integration and CICD tooling allows you to validate your release packages ahead of time and promote work along your pipeline.
You can also automate things like unit testing to avoid failed deployments due to low code coverage.
And automated monitoring and backups mean you can identify and restore any issues that might develop in your production environment as fast as possible as well as providing more transparency to your team.
Automation isn't just about speed, though. According to Puppet's latest DevOps report, ninety seven percent of teams with highly evolved DevOps practices say that automation doesn't just increase velocity, but crucially improves the quality of their work too.
When you automate parts of your workflow, you free people up to focus on delivering further improvements to your development and release process.
So as we've just seen, empowering your people with the right tools and processes lets your team build together better and faster.
When these three components work in harmony, you're well on your way to DevOps success, and, ultimately, you'll get more ROI from your Salesforce investment.
All this sounds great. Right? But perhaps you're wondering, you know, how do you make it a reality?
There are different approaches to implementing DevOps and then maturing those processes.
The least successful in our experience, at least, is this big bang approach adopting everything at once. And just nine percent of the highest performing teams in terms of DevOps performance adopted DevOps with this big bang approach according to the twenty nineteen DOR report, which is this amazing industry, collection of of companies that analyze this type of thing.
While you might find a tool that does everything you want from the word go, you need to be wary of imposing several new processes on your team without getting their buy in.
Take GearSat, for example. You can set up an entire DevOps workflow within about thirty minutes, but you're gonna need help from your team to make the most of it. Help them see the value in your chosen processes and continue to do so as your processes become more complex.
Likewise, before implementing new ideas, analyze how strong your existing foundations are. For example, you'll want to have a high rate of, you wanna have very high rate of successful deployments, before you implement CI. In fact, no matter how developed your DevOps strategy is, you can always build on your improvements to further fine tune your strategy.
So the race to DevOps success is a marathon, not a sprint.
So if improving process if improving your DevOps process is gradual, your next step is to work out, where your team is currently at and then decide how best to increase your impact as a team. To that end, I'm gonna leave you with some questions.
Are you investing in your team and are you investing in their training?
What part of your process have you changed recently?
Have you got your team effectively collaborating?
Are folks still, stepping each other's toes? And do you have steps to, you know, get towards that next stage of your maturity?
Your challenge is to work out which of these next steps to take. Of course, maybe it'll be all of them. Maybe it'll be some of them. At Gearset, this is what we do. We help people with this type of thing. So if you want a one on one assessment, you can go to Gearset dot com slash assessment, and you'll have a session with either myself or one of my colleagues, and we'll sit down, think about where you're at in your in your maturity, where you're trying to get to, and make sure that we're there to support you.
As I say that if you want to, book that session, then you can just go to gearset dot com slash assessment. But it's been an absolute pleasure speaking to you all today. And thank you very much, and I hope you enjoy the rest of the summit.
