Andrew Davis is an 18 x Salesforce Certified trailblazer. He is a Salesforce DevOps specialist who’s passionate about helping teams deliver innovation, build trust, and improve their performance
Main Points
The main points Andrew talks about:
- Understand DevOps in general
- How does DevOps progress in Salesforce
- Principle 1 is about the left-to-right flow
- The following Principle 2: the right-to-left feedback loop
- The last Principle 3: learning culture
- Andrew’s Salesforce DevOps book — publishing on DreamForce 19
Links
- Andrew’s Twitter handle
- Andrew’s homepage
- Andrew’s book – Mastering Salesforce DevOps: A Practical Guide to Building Trust While Delivering Innovation
- Book – The Phoenix Project
- Book – The DevOps Handbook
Video Teaser on Andrew’s Salesforce DevOps Book
My Own Thoughts on Salesforce DevOps
DevOps is no longer a new topic in the IT industry. Many gigantic companies like google, facebook, Airbnb have all done fantastic jobs around DevOps.
Despite the challenges of implementing DevOps in the past, Salesforce is catching up with the help of DX and related new features.
In this episode, Andrew started by guiding us through the most important principles in the DevOps world. He then also introduced some of the tools he talked about in his new book — Mastering Salesforce DevOps: A Practical Guide to Building Trust While Delivering Innovation.
In my opinion, it is far more important to learn the guiding principles than knowing how to use and configure some tools. This is also why Andrew mentioned the two famous DevOps books – The Phoenix Project and The DevOps handbook.
The Phoenix Project book reads like a novel because it is a novel (haha!). The story told in the book is very attracting, I felt like it was exactly what happened in the company I was working in.
The DevOps Handbook complements and extends the content of the phoenix project book. It is more of a holistic view of what DevOps is and is not.
If you want to be a cool DevOps guru, check the two book links above!
At last, you might be also interested in Episode 9 where Quality engineer Ari Luokkala shared about the automation tools in Salesforce.
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:18] This is Salesforce Way podcast. In each episode, a guest is invited to talk on one specific subject. Our goal is to help our listeners to not only become better Salesforce developers, but more in general, better software engineers. So, hope you enjoy our content.
[00:41] Hey, everybody, it's Xi Xiao here, and this is yet another episode of Salesforce Way podcast. Today I'm sitting with Andrew Davis. Hello, Andrew. Hello, Xi. Nice to be here. You're welcome. Would you like to introduce yourself? Sure. Yeah. So my name is Andrew Davis. I'm a Salesforce developer and architect, and with a focus on release management and continuous delivery DevOps. So I'm worked at Apereo for five years, and now I'm working with Copado as a product manager for them. I'm based in San Diego, California. Just a lovely place. That's one of the places I definitely want to move
[01:27] to. Yeah, I also understand, Andrew. You have. A secret. You have a book coming out very soon, right? Would you like to introduce that to our listeners as well? Sure. Yeah. So you've you've opened up the secret, but yeah, I'm happy to share that I'm writing a book, or I've written a book, and it'll be coming out in time for Dreamforce 2019. So it'll be a book entitled Salesforce DX: Practical Guide to DevOps for Salesforce. So covering the topic of how to apply DevOps principles for Salesforce. So in this session, you're gonna coach me a little bit the content from your book, the principles. Yeah. That's perfect. That's great. I'm happy to go through that. It's also good for our listeners. You know, the DevOps has been, I guess, in IT industries for more than a decade. Yes, I understand. Originally, it was like from the lean process from from Toyota, and then we have multiple principles coming out, and people writing books and how to adapt those principles into the IT industry. But for Salesforce, it has been not such a smooth journey, right? Because Salesforce either it's a work-based kind of development model, and it's hard to pull out the metadata in the past. But now the things are getting much smoother, and it's kind of aligned
[02:58] with the mainstream development. And the CI/CD, actually nowadays, it's already a topic in agenda for Salesforce developers to learn. That's what I understand. Yeah, no, that's exactly right. Yeah, the DevOps, the term originated in a talk from John Allspaw and. I think it's 2009, 2008. About DevOps together, 10 deploys per day, and that has the term DevOps has become a gathering point for a number of sort of related movements, especially the lean software movement, combined with continuous delivery, sort of on the technical side. So the the condensed version is. It's lean, lean software development, together with continuous delivery as the technical implementation, as a way to expedite releases and testing of of software. And as you say, Salesforce is still just catching up, but it's it's sort of reached this fever pitch within the Salesforce community of people wanting and needing to adopt these kinds of practices. So that was certainly what I felt within Apereo that there was a lot of Growing need and wish for guidance on how to do that, and then I, that's reflected broadly in the Salesforce community. If you look at the number of talks at Dreamforce and Trailhead DX about these topics, it's keeps growing. It's obviously a big interest.
[04:28] Yeah. You you just mentioned that the DX come online. You also mentioned like some practical tools for automated Salesforce. Also, they are guiding principles, right? So, for me as a beginner, how do we start the conversation? How would you introduce this big topic to me? Sure. So the big topic, I would say, is.
[04:55] Everyone, whether they know it or not, they follow some software development life cycle. There's always some process of creating things, testing things, releasing it to users, and so DevOps is looks at that whole software development life cycle, software delivery life cycle, and begins to poke and prod and figure out how we can make that whole process more efficient, because there's a lot of inefficiency in the way that. People build and deliver software in general, and that's definitely true within the Salesforce world. Time spent waiting, for example, if you build something in you know development sandbox or in a scratch org, it might take you some time to get it over to a testing environment where people can test it. People are waiting maybe for that work to be released to the testing environment and. There's no test automation, perhaps, and then there's a lot more waiting and waste getting it to a production environment where you can start to get feedback and, and so the idea with DevOps is just take a look at that whole life cycle, and begin to. Figure out what you can do to make it more efficient, more effective, so you close the the gap, both in terms of time and pain and effort between building something and getting people using it. That sounds like a really higher level. From what usually one developers is doing in the project, a one individual developer usually
[06:26] it focuses. Hundred percent on his own individual task. Like the the code I created, I commit to the GitHub, and I make sure it works in my local environment. And how does it really work in the test environment or in the QA? And how to transfer? My changes to those testing environments. That sometimes is like a technical limitation is also one of the reasons. Like if we use the change sets, maybe it's much slower and less efficient than modern tools such as the DX, right? There were kind of different gaps, different types of gaps. Yeah, you know, there's a lot of angles you might come at this question. And if you're starting from the point of view of an individual developer, your area of focus is just, you know, it's hard enough just to build something, and then you move it over to a testing environment, make sure it works there, and the permissions are right, you know, and that's hard. And by the time you get something tested. You really want to move on. You're a little bit tired of working on it. There's a lot of pressure to move on to other features, and so, and so it's it's common that developers don't necessarily. Think about how the whole process could be optimized, or if the whole process could be optimized. And the big focus for developers just build something, move on, build, move on, build, move on. And from the business point of view, you know they're looking to get features delivered, but there's a black box where they don't quite know what's
[07:56] going on with the developers. It's very different worlds, and so. The developers might say there's a delay, but the business people can't quite understand the technical reasons. And so DevOps definitely requires you to look at that whole process at a higher level. If you're coming from a developer background, you definitely have to. You know, pull yourself out of the code. Look at the whole process end to end. Is it efficient? Are we being able? Are the things we could do to deliver capabilities more more quickly? And if you're from a business point of view, you need to think about you know what can we do to help IT you know to set things up so that we can actually get features delivered more quickly. And maybe maybe the point is not to always be driving. One hundred percent to focus your energy on building new features. Maybe there you need to recognize you have to invest time in improving that development process and the life cycle.
[08:56] So is DX the the tool to remedy all these? In Salesforce, unfortunately, the tool, the magic tool that remedies all of this, has not yet been invented. I'm sure there'll be some artificial intelligence-powered robot in the future that will just solve all of this. But Salesforce DX definitely is. Building the right foundation and helping us to move in the right direction, and doing a lot to enable a more efficient development process. Salesforce DX is stands for Development Experience. It's the name of this, you know, originally some Tiger team that Salesforce spun up maybe three years ago to begin to reimagine the development lifecycle, how they could do it more effectively, how they could support developer collaboration, and now DX is this. Very big area of the Salesforce product and engineering team. It's probably a hundred people or something, all under this banner of Salesforce DX, and it's really everything to do with custom development on the Salesforce platform.
[10:04] Especially the code-related aspects of that, so all of Apex falls into that. All of the environments and orgs, not just scratch orgs, but yeah, Salesforce has begun to build a really robust foundation and really helped invigorate a lot of people who are experimenting on this already, and giving them a new way to build things. And so there is a ton of experimentation. Tools being built. You know, some individual companies are experimenting with how they can use Salesforce DX to build their processes. Products like Copado and my previous company, Apereo, Apereo DX, working to build tooling on top of this to to make the whole process easier. Hmm. So we just talked about, like, from a higher level picture, how to build a fast and efficient flow for any Salesforce solutions. But in addition to that, I understand for DevOps, there's a very important concept. It's like a feedback loop. So in the past, the Salesforce is always kind of slow. You have to send it to the cloud, you have to compile, and then you get the feedback to your local environment. Is there any like feedback loop from that point of view? Do we have like a better tooling nowadays with the DevOps concept? Yeah. So, like you say, within DevOps, the idea of a feedback loop
[11:34] is really important. The probably the nicest, most concise summary of of what DevOps is all about was given by Gene Kim in books like The Phoenix Project and the DevOps Handbook, where he refers to these three movements: the movement of Development and features from left to right, from a development environment to testing to production, the movement of feedback. From right to left, and that means feedback from end users and feedback from testers, but maybe also feedback, you know, instantaneous feedback like linting tools and Apex unit tests. So the first movement I like to summarize is continuous delivery, is the left to right movement from dev to prod. The second movement I like to call continuous feedback, just for the poetry and symmetry of it, getting feedback from Production and testing as fast as possible, and the third movement is continuous improvement. And continuous improvement, the Japanese word is kaizen, which you know comes from the Toyota production system and the lean movement. But the idea is that you start where you are, which is always the best place to start, and just make continual improvement. And so there's no there's no final arriving. There's only continual improvement. So. Like there's this Zen saying, you know, what is before enlightenment? Let's chop wood and carry water. And then, what is after enlightenment? What is after enlightenment is chop wood and carry water. So, what is before DevOps
[13:05] enlightenment is continuous improvement. And what is after DevOps enlightenment is continuous improvement. So, all the best names in this area, Amazon, Facebook, Google, you know, Netflix, they're all fully focused on just how can they keep improving. From from everybody else's point of view, they're super advanced. From their point of view, they're always just looking at the their limitations and moving forward. Because we talk about the feedback loop, how I understand. As a developer, when we write code, each time when we type a word or hit a dot, we always want to get the feedback from the editor from the IDE. So we want to see the compiler either throw back an error, or when we hit the dot, there's the intelligence to tell us, okay, what is the method popping up when we hit the dot? That's the feedback. So that's really like a fastest feedback loop, and then from the project point of view, of course, it's a much larger scale. If you build some automation testing, right, like a unit testing, each time when you deliver some new features, those unit test is like the first round of the feedback loop for you. And then there's manual testing, maybe there are UI testing. Those are like a second, a third round of the feedback. So the longer the feedback loop, the the harder it is to change. That's that's how I understand it.
[14:36] Yeah, no, that's perfect. It's a great summary. There's all of these different levels of feedback, and like you say, developers maybe we're just an impatient species of creature, but we like that instant feedback in the IDE. And so, I think people, even though there's still some gaps in in Salesforce's extensions for VS Code, everybody likes VS Code. And as well as some of the other IDEs like Vulcan Suite and Illuminated Cloud, developers love the aspect in that where you can get real-time feedback like linting, like embedding PMD to give you feedback on your code, code you know syntax highlighting, auto formatting. You know, un you know, highlighting things that are unrecognized variables or unrecognized keywords. That's the best feedback that developers love most of all. And the longer things go on. Then the more painful and inefficient the whole process is. So, if you as a developer write something, and you have somebody sitting next to you. Saying how they want the user interface to be, and you can move the fields around. That is fantastic. You've got high bandwidth communication with that person. The feedback is instantaneous and iterative. If you create something and then it stays weeks and like even months before it eventually gets out to users in production, and they're like, oh, can you remove this field or change this field and so forth? You know, you you have to come back to that where that work. It's context
[16:07] switching, right? To come back to that and try to remember what, how you built it. It's so complex, you know. This. It's really hard to remember, and it's inefficient to have to go back, dive in, and make those changes if they if they have to be made days and weeks later. Yeah, I remember I had a conversation with one of my colleagues. We say, in Salesforce, what if we can just click one button, then it's deployed to production, and end users can test. If they found found any bugs, we can click another button to roll back to the previous stage. That would be the ideal world. Yeah. Yeah, yeah, yeah. That's the ideal world, definitely. But we're aiming for that at least. We we have to aim high, you know. That's what you just mentioned, like a continuous improvement. Improve your your entire process to make it more efficient day after day and month after month. Yeah, exactly, and that's kind of the essence of continuous delivery. On the technical point of view, it's the process of. So these terms get thrown around a lot and sometimes misused. But the original idea of continuous integration is to make sure that all the developers are working. Either on the same trunk or they're integrating their work at least daily, but then the risk of that speed of of integration is that people can break things without anyone noticing, and so that's why automated testing becomes
[17:38] so important in continuous integration, and tools like you know Jenkins or GitLab CI that can run those tests becomes so important, and then continuous delivery layers on automating the deployments on top of that, and so that's where the You know that's kind of the heart of the technical heart of DevOps is implementing these automated tests, automated deployments. Figure out, you know, just can certain kinds of metadata be expedited to production. You know, do other kinds need more sophisticated tests? When do you need manual tests? All of those are within that realm of areas to focus on and see if you can improve. I got it.
[18:26] Hi, just a quick note here. Don't forget to check the links shared in the show notes, where you can find the guests' contact information and the important complimentary materials for each episode. In addition, I'd be so happy if you could share with me what you think about this podcast. You can reach me out by email, Twitter, LinkedIn, or website contact form. Your comments would definitely help me improve and deliver better content. So now let's get back to the show, shall we?
[19:04] Um, but in the IT industry, there were a lot of continuous integration, continuous delivery tools. But a lot of large organization, they are still failing to use the DevOps concept. I heard maybe you can correct me if I'm mistaken. Is that you also need to have like a learning culture in the team, even in the in organization called like a learning organization? You have to. Encourage people to try those new stuff, and a lot of time they they may hit the wall. They may have some mistakes or even catastrophic issues coming up. But you have to encourage them and let them know that there's a trust here. So, is your book also touching those part of those cultures? It it does you know the topic of culture is hugely important in the DevOps world and many authors and commentators have said you know DevOps is really about culture change and culture shift and it we. The book touches on that topic of culture, but it goes into a tremendous amount of depth on the technical capabilities you need to build. And so the book isn't a comprehensive guide to how to change your culture, but definitely speaks to the importance of that. And you know when I mentioned the idea of continuous improvement. So, DevOps is about increasing
[20:35] the velocity with which you can develop innovation or deliver innovation, but as well increasing your degree of confidence that you can deliver that innovation safely without things breaking. But then there has to be a learning. Culture in place. There has to be a culture of trust in place, from lots of different angles. Because if you're increasing, for lots of reasons, but if you're increasing the speed of things, so first of all, to to go through this process requires some experimentation. You're not going to get it right the first time. Maybe you're going to accidentally deploy some things that you shouldn't have deployed, and it's going to be. Rocky to get started. So, the company has to have an environment in which you can experiment, at least in these processes, to get things started. But more importantly, once you get these processes underway and you're starting to increase the. Velocity with which you deliver things, you're gonna be delivering. If you're delivering to production more quickly, you will also be delivering bugs to production more quickly. And there has to be a certain degree of tolerance for that in the business to recognize that that's going to happen. But that every time it happens, that becomes a learning opportunity. It doesn't become a a cue to punish someone, which is the you know the opposite mindset. It's sort of a pathological mindset that failure leads to punishment. So in the DevOps world, you talk about these three kinds of cultures: a pathological culture, a bureaucratic culture,
[22:05] or a generative culture. A pathological culture: failure leads to punishment and scapegoating and fault finding. And a bureaucratic culture: failure leads to justice in the sense that everything's around rules, following rules in a bureaucratic culture, so that. If you break the rules, there may be some consequences. But in a generative culture, failures lead to inquiry, and failures lead to investigation, and it's the starting off point for making everything better. You know, if you think about these big failures that Salesforce had a couple months ago with these Permageddon deploying all these you know permission changes, yeah, it was a mess. It was a mess, but. Salesforce has learned from that. I'm sure that's not that particular problem will never happen again because they take it as a starting off point for adding new protections. You mentioned in your book you went into a lot of technical details. So what are those technical details? As a developer, you know we are always curious about that. Sure. Yeah. So, the book has has four parts. I divided it. The first part is about sort of a general introduction, introduction to DevOps, introduction to Salesforce, and to Salesforce on DevOps. So the first part is the most sort of readable, high level aspect for less technical users. Then the remaining part, I I had a section on Dev. Or development, a section on ops or Salesforce administration at the end, and then in
[23:35] between the main chunk of the book is this big section on delivery, software delivery. So in between dev or creating things and ops and using things, there's this whole software delivery process, and that's really where the meat of the book is. The technical topics in the in the section on development. There's a big chapter on architecture, which talks about some of the new architectural patterns that are becoming more important when you're starting to look at using Salesforce DX and unlocked packages, things like dependency injection and Apex Enterprise design patterns, and so forth. So we talk about that in the development section. The software delivery section then goes into a lot of detail on. How do you use version control? What kinds of branching structures are most appropriate? Whether if depending on whether you're using or the org development model or the package development model, how do you build packages? How do you specify? How do you do different kinds of testing? So quite a lot of detail on. You know, static analysis, unit testing, JavaScript unit testing, Selenium, Provar, those kinds of things, and then on to deployment. I've got a summary of all of the commercial release management tools like Auto Rabbit and Gearset and so forth. I've got some summary of those in there, and then about other topics like how can you deploy things without actually releasing them to production. That that's very cool. I I can't wait to get your book. So where can I order the book from Amazon or somewhere?
[25:06] It's a little it's a little premature, but but keep it in mind. And in a couple of months, it should be possible to pre-order at least. Yeah. Okay, I'll definitely buy that book. Great. All right. I guess we had a really good conversation about DevOps in general for Salesforce. Um, I love what we just mentioned. You you touch like the the flow from left to right. You also touch the feedback loop from right to to to left, and also a little bit about the learning organization, the culture, and then you also went in depth. About like the technical aspects that which developers always really fond of. So, is there something else you still want to add before we close the session? Well, first of all, really grateful for you inviting me here. It's really nice to have a chance to talk about this and to talk about these topics. I would say, just in general, as I said in the beginning, it's a topic of really strong and increasing interest for people in the Salesforce world and the tech and the Although Salesforce is a little bit late, getting you know a little bit late to the party, to the DevOps party that most people are. You know, just starting to look at learning version control and automating deployments and testing. There's benefits to that because the benefit is that there's a ton of good writing already on DevOps concepts. There's a ton of good tools that are available, and what I've done with the book is to try to
[26:36] summarize a lot of that. You know, to try to make it like a first stop for people in the Salesforce world who are interested to know more about DevOps and and the research on that, and then. The way that the DevOps culture has evolved is very, very helpful in terms of uniting the business needs and the technical needs. Because one of the big challenges is that it's hard for technical teams to get the funding or the understanding or the The permission from the business to invest in these kinds of things, but the point of DevOps is to begin to look at how IT can drive innovation for the business and how IT can become a profit center for the business instead of the cost center, and the importance of this kind of agility and automation for doing that. And so, when you frame the idea, if you if you think about version control as just from an individual developer point of view. Of course, we understand the needs to track our work and automate deployments and so forth, but it's not so compelling for the for the business and our bosses, bosses, bosses.
[27:45] So DevOps takes that high-level point of view. It's like, okay, how fast are we able to deliver right now, and what could we do to be able to deliver innovation to the business more quickly and more safely, and how can we continually improve? And so it sort of builds in the idea that it's a collaboration across the entire organization, and that and that it needs to be approached in a sustainable way. And the way to make it sustainable is to always focus on the on the. On increasing the business benefits that IT can bring, and then it becomes a win-win situation where the developers get to use more effective, efficient tools and reduce a lot of the pain in the software delivery lifecycle, and then the business gets the benefit of much, much greater agility. Yeah, so it's an exciting time. Yeah, yeah. And my word to our listeners is that just don't close the door. You know, it's an opportunity. DevOps is a hot potato in the industry, and Salesforce is catching up. Definitely, there's a gap here. There's a lot of talents are needed about the DevOps, and if you're you're really interested in like building those tools, make the automations, to understand how to fast create the business values, this is something for you. And since you have a developer background. Those tools, those configurations are really easy to learn. You need to understand the principle,
[29:15] and then the tools are just you know to play around and and then use the learning opportunity, improve it day by day. Perfect. Yeah. All right. Thanks, Andrew. Yeah. Great talking with you. Yeah. Good luck with your book as well. Thank you so much. Bye bye. Hey,
[29:41] this is the end of the show. If you enjoyed the content, please connect with me and let me know your thoughts. All my contact information is available on the website at SalesforceWay.com. Thanks for listening. See you next time.
