David Reed is a Lead Member of the Technical Staff over at Salesforce.org. Today I talk with him about all things CumulusCI, the open source continuous integration engine that they created and support.  Tune in to learn details about how developers can leverage its many features and companion applications.

David is not only interested in computers but also very into history and classics. He even has a Master’s degree in ancient Greek. Tune in to hear more from him and learn tons of information on CumulusCI.

Show Highlights:

  • How David learned Salesforce.
  • What he does in his current role.
  • What drew him to automation and the DevOps cycle.
  • Why CumulusCI can be called portable automation.
  • Why it’s easy to reproduce in Cumulus.
  • The pain points that it can solve.
  • Tasks that it can automate for both admins and developers.
  • The advantages of Python.
  • How to layer CumulusCI on top of your current process.
  • What Program Management Module is.
  • Goals for the future of CumulusCI.

Links:

Episode Transcript

David Reed:
Writing code and writing a very complex dead language that is not currently spoken by any community of speakers are remarkably similar to one another in some respects.

Josh Birk:
That is David Reed, a lead member of technical staff over at salesforce.org. I’m Josh Birk, your host of the Salesforce Developer Podcast, and here on the podcast, you’ll hear stories and insights from developers for developers. There, David was talking about the overlap between two of his big interests, that’s being history and classics and computing. He’s got a master’s degree in ancient Greek, by the way. Today, we’re going to sit down and talk with David about all things CumulusCI, and we’re going to start as we often do with his early years about how he got into Salesforce, which by the way, was also through nonprofits.

David Reed:
Yeah, my job when I was a nonprofit admin was running the Raiser’s Edge instance and my organization came up against problems that I think are common to lots of nonprofits where we couldn’t extend the system to, which is another nonprofit CRM, to serve our unique needs and we were frustrated by the high cost of the system and the lack of an open ecosystem around it.

Josh Birk:
Got it.

David Reed:
Those were the factors that really drove us to Salesforce. When I first met with a Salesforce partner and started talking about of the system and they said, “Oh yeah, you get access to the API. You can build your own integrations and design tools to manipulate your data.” My jaw dropped, I knew this was what I wanted.

Josh Birk:
Nice.

David Reed:
So, we worked with a Salesforce partner to do the transition from Blackbaud Raiser’s Edge into Salesforce, and that was a really good experience. We became Nonprofit Success Pack customers right away.

Josh Birk:
Gotcha.

David Reed:
So I learned Salesforce on the Nonprofit Success Pack.

Josh Birk:
Oh.

David Reed:
Which is one of the teams that I support now, and I’m thrilled that I get to do that here as part of .org. Really, my advice to nonprofits that are thinking about that kind of transition is to think big, to imagine all the things that you potentially could do if you had more ways to interconnect your data than you do today. That’s what I see as one of the core merits and values of both the platform and the Nonprofit Success Pack in particular.

Josh Birk:
Gotcha. Gotcha. So now I think you just answered my next question. You kind of used… So you had previous technical background, but then you kind of used NPSP as a learning tool to learn how Salesforce works and how to develop on it?

David Reed:
Absolutely. I started with the Nonprofit Success Pack. I taught myself Apex and was fortunate to be able to attend my first Dreamforce, where I picked up my first Salesforce certifications a little bit later in that process.

Josh Birk:
Nice. That’s awesome. That’s awesome. And when do you feel like you started branching out to consider being more of an architect?

David Reed:
A position or two after I worked in that nonprofit, I guess.

Josh Birk:
Okay.

David Reed:
I probably could have thought about myself as an architect at that time because I was the one wearing all the hats. I was the only one.

Josh Birk:
Yes.

David Reed:
Doing development on the Salesforce platform. But once I moved a couple of positions further in, I was on a larger Salesforce team and took on the role of defining best practices and laying out the system architecture, working on CICD and other systems integration type topics is when I was first titled as an architect and started to think of myself that way.

Josh Birk:
Got it. Okay. Tell me about joining .org and kind of describe your current job for me.

David Reed:
Yeah. I got to know .org through the community. I was living in Philadelphia where there’s a wonderful community of .org folks, including Judi Sohn and Michael Smith in particular, and I got to know them through the local PhillyForce community. Some of the community conferences out there that multiples of us were participants at the same time, so we got to know one another. I became aware of .org through that community connection and what drew me in to the job that I now occupy is this opportunity that those folks shared with me to do work on the Salesforce platform with Python, which I also spend a lot of time working in, and specifically in the area of automation, which is something I’d really become passionate about doing CICD, workflow automation, not just in the platform with tools like flow and process builder, but around the platform to help build better applications and do better deployments.

Josh Birk:
So tell me a little bit more about that. When was the first time you used, encountered, CumulusCI and started to feel like you had to lean into that automation and DevOps cycle?

David Reed:
I realized when I interviewed with salesforce.org, that I’d actually used CumulusCI several years before.

Josh Birk:
Nice.

David Reed:
And what I now know was an earlier iteration of the product.

Josh Birk:
Okay.

David Reed:
I was using DX and trying to solve some orchestration challenges around DX for complex end user. I was working at financial services at the time, and I caught the use case. I understood the use case of CumulusCI as soon as I heard it from the folks that are now my teammates at .org. It’s an orchestration layer. It helps you run reproducible builds, create new environments that are fully configured and ready to do work in of many different kinds. That’s what I needed in the job that I had been working before salesforce.org. So I came in ready to evangelize that vision…

Josh Birk:
Got you.

David Reed:
And start using it and extending it.

Josh Birk:
That’s nice. Awesome. I was about to ask for the elevator pitch for CumulusCI itself, but I think that’s a good one. So I think that that kind of sells that pretty well. But I’ve seen in some of your presentations, you describe CumulusCI as portable automation. What do you mean by that?

David Reed:
Portable automation is our concept framework for everything that we do, and I find portable automation to be, in some ways, an easier entree into our work than CumulusCI itself, because…

Josh Birk:
Okay.

David Reed:
What we want to think about and encourage our users to think about is where can automation play a role in your development life cycle? Especially outside the traditional scope of automation. So lots and lots and lots of product teams and end users have automation in the CICD sense, right? Or the deployment sense.

Josh Birk:
Mm-hmm (affirmative).

David Reed:
You run a build and you get back test results that tell you whether or not your application’s working as expected. But what portable automation emphasizes is you can create orchestrations that do valuable work on the platform, like setting up a complex Salesforce org, so that it’s ready for someone to sit down and operate in. And you can pick that automation up and consume it in many different contexts and through different user experiences. And by doing so, you add more value across the whole development life cycle.

David Reed:
So I’ll give you an example, right? You’re building an application that needs two things. At the beginning of your process, you need to do configuration in the org to set up a Salesforce feature like multicurrency, for example. And then you push the application into the org and in order to do useful work, you also need to load up a complex data set, like a CPU configuration, or example data for your app to use. And those things take a while. It might take you a couple hours to fully set up an org. So you build automation to do those steps, because you need it to run in your test platform before you release new versions of your application. That’s kind of the traditional model, but what portable automation emphasizes is that that automation you’ve created has value if it’s portable and it can be picked up and taken to other parts of your development process.

David Reed:
A developer, for example, might need to spin up a new scratch org to do a hot fix. They shouldn’t have to spend that two hours to configure their environment. That slows them down. But not just developers, but also QEs need that kind of functionality, right? If you’re going to test the app in a manual QA workflow, you also need an environment. That’s one expansion.

Josh Birk:
Okay.

David Reed:
But the next level of expansion and the one that I personally find most exciting is the idea that you bring in other users who might not have traditional technical backgrounds as well.

Josh Birk:
Okay.

David Reed:
And provide them with that portable automation to help them do their jobs. Like a PM, for example, might consume some of your automation to set up an org for them to do a demo to a potential customer, or your support team might use the same automation to set up an environment to replicate a customer issue and be able to triage it more quickly. So you can expand the umbrella in several different stages through portable automation of where you’re bringing that value into your development process.

Josh Birk:
So defining portable here as in the noun orchestration should not be something that’s static and in some ivory tower but something that anybody along the DevOps chain can pick up and reproduce.

David Reed:
Absolutely.

Josh Birk:
Got you. Well, dig into that example a little bit more for me, what does Cumulus or, and I guess I should level set, or let me allow you to correct me if I use Cumulus where I’m actually referring to something in the ecosystem that .org has created that may actually be another tool. I acknowledge I may be using Cumulus as kind of an umbrella term here, but what in Cumulus is kind of special that makes particularly that task, because what you’re describing is so core to, and you just told us why it’s so core, because there’s so many people who need to be able to reproduce an environment. What in Cumulus makes that easy to do?

David Reed:
What makes it easy is twofold, I think. One, we define automation in a simple text-based markup format. It’s just YAML, and that file becomes part of your product, in essence. It lives in your version control repository alongside your code. It gets versioned as your application is developed. So that’s sort of the traditional development workflow.

Josh Birk:
Yeah.

David Reed:
But then that automation gets consumed through multiple different entry points.

Josh Birk:
Okay.

David Reed:
If you’re a developer, you probably consume it through the CCI command line tool. If you are a quality assurance tester, or if you’re an automated system, you might consume it through our MetaCI continuous integration tool, or your own Jenkins or GitHub actions or other CI harness. And then again, if you are a declarative developer or an administrator, or if you’re a non-technical user like a product manager or a support technician, you could consume it through MetaCI or through Metecho, our web user interface for bringing those users into the SDLC.

Josh Birk:
OK. So dive a little more in that. Is there a distinction in what an admin sees through the web UI versus what the developer is seeing through the CLI or are you just finding touch points that people are familiar and comfortable with?

David Reed:
I think it’s more the latter.

Josh Birk:
Okay.

David Reed:
In terms of functionality, we try to keep everything available as much as we can through every experience. So if a developer and a quality assurance tester are building the org through the command line and then through MetaCI, they should get exactly the same results.

Josh Birk:
Okay. Now let’s kind of roll back a little bit, because we’ve kind of described a little bit of the value for something like Cumulus, but when you were at that position where you knew you needed a tool like CumulusCI, what were some of the pain points that you were experiencing that only through what we’re describing right now were you’re going to find a solution.

David Reed:
What I found in that role and what I see a lot in the community as well is that the kind of problems that we build frameworks for in CumulusCI are problems that are typically solved ad hoc in other contexts. Every end user, every ISV, has to reinvent the wheel. And when they do reinvent that wheel, it’s usually in the form of bash or node scripts that are… Some people do that very well, of course, but in many cases.

Josh Birk:
Right.

David Reed:
Those scripts are very specific to a single use case, they pose maintenance or technical debt challenges, and they also pose challenges in the sense that maybe one person on your team really knows how it works and you don’t have the ability to share that effectively across your organization.

Josh Birk:
Gotcha. Gotcha. And when I am that person who has those bash scripts and those node scripts, and for the record, I have been that person in the past, so I’m totally guilty there. How easy is it from me to move that kind of stuff into a proper system like Cumulus?

David Reed:
I think it’s usually pretty straightforward. What I find is that many of the problems that exist in the community around that kind of orchestration, like as one example, progressive uninstalls when you remove elements from your source tree, removing them also from orgs, that’s a problem that we’ve seen for many, many years. So we just solved it in our framework, and it becomes out of the box. And I think that’s one of the advantages of the framework approach of formalizing this automation, so that those kinds of problems just become solved problems, and the transition from a bash based orchestration to Cumulus based orchestration can mostly be deleting code that you don’t want to maintain anyway.

Josh Birk:
So if I’ve got my old trusty bash script, it may just see something that doesn’t actually need to exist anymore?

David Reed:
Most likely, yeah. That bash script would become a YAML markup flow in CumulusCI, and in many cases, CumulusCI users don’t have to maintain any imperative code whatsoever.

Josh Birk:
So let’s walk through a couple of those kind of features. What are some things that Cumulus does out of the box that developers and architects might not realize that are tasks that it could easily automate for them?

David Reed:
I’ll give you three things that I think are killer apps.

Josh Birk:
Okay.

David Reed:
That are longstanding problems that we think we have a solid solution for. One is dependency management. Dependency management’s hardened almost every technical ecosystem in some way or another. We’ve built a system for dependency management in CumulusCI that relies on GitHub and GitHub releases to identify versions of the application and allows you to dynamically resolve references between your project and other projects at build time. So you never have to manage dependencies by hand. You don’t have to update package IDs or anything like that. It all should just work and give you the result that you’d naturally expect. And that’s particularly compelling, I think, for ISVs or customers that are heavily invested in the package development model, where you might have a complex hierarchy that you need to maintain as part of your app. So that’s one.

David Reed:
A second feature that I think is killer is the ability to abstract out setup as part of your automation from the build of your app itself. So you might have a flow, for an example, that satisfies all your dependencies and then installs your application in an org, and then you can compose that automation flow with another flow loads up a data set for you and sets up Salesforce platform settings and maybe creates a couple of additional users or performs some other automated setup to make the org look the way that you need it to look post-installation so that you can start doing work.

David Reed:
And lastly, I think I’ll call out an aspect of that, composability, as a killer feature, because CumulusCI uses a flow model, and that terminology can be a little confusing. It’S not visual flow on platform, but we model our automation as flows that compose tasks and other flows.

Josh Birk:
Okay.

David Reed:
And we make it very easy within a project to define building blocks of automation, assemble them to serve many different needs, including needs you might not have initially anticipated, and then further compose them across different products that need to inter-operate.

Josh Birk:
Gotcha. So how easy is it to handle deltas in something like that? So for instance, and first of all, just shout out to the value of having an org look the way that it should, like akin to a production org, having been the person guilty of using the vanilla developer edition org for going on a decade now. But if you’ve got the developer who is trying to finish ouT their branch, you’ve got the UAT person who’s trying to do acceptance testing, you’ve got the business user who just wants to do the demo. Are there times that those people have small needs that are different from each other? And is there a handy way to handle the delta, or is the goal just to make one org that will kind of appease them all in one automation?

David Reed:
There is a way to satisfy all of those needs.

Josh Birk:
Okay.

David Reed:
And the root for doing that really is an application of that composability principle.

Josh Birk:
Okay.

David Reed:
So imagine, again, for example, you’ve got a flow in CumulusCI that satisfies all your dependencies and then installs your product.

Josh Birk:
Got it.

David Reed:
On top of that, you can compose a configuration flow, but you can have more than one configuration flow.

Josh Birk:
Got it.

David Reed:
You might, out of the box for example, you get a configuration for developers and a configuration for QA testing. You can then add your own for config demo, for example, or config tech support. And you have the freedom to remix all of those automation elements to suit your specific needs. So each one of those users, when they sit down to start a project, can get an org that is built on the same foundation as everyone else on the team, but is tailored to their specific needs and workflows.

Josh Birk:
And all these things that we’re describing, being able to create a flow, control a flow, customize it like this, to just kind of reiterate, those are all these things that are available under the different interfaces that you were talking about. So an admin can do these tasks or developer can do these tasks?

David Reed:
Absolutely. Defining the flows themselves is just making edits to a text file.

Josh Birk:
Got it.

David Reed:
A YAML file that lives in the repository. Then running those flows is something that you can expose through these different experiences, whether it’s command line or web UI, or even our web UI for delivery directly to customers.

Josh Birk:
Okay.

David Reed:
Who are also a persona that consumes your product’s automation.

Josh Birk:
Got it. Now I know .org loves, but actually I’m going to ask this question to all the .org people I get onto the show. Why do you all love Python so much?

David Reed:
Well, obviously there’s always some level of inertia, but I think we love Python and I think we’ve chosen Python on for so many of our use cases because it’s a language that works really well for the kind of rapid prototyping, open source community-focused development that we do and that we love. That’s a big part of our ethos. When we do an open source community sprint, for example, we set up lots of people with CumulusCI or with Metecho, our web UI for portable automation, and some of those people ultimately will go on to make Python contributions to CumulusCI because they came up with a new unit of automation that has value to other people. When we want to add something to our toolkit or bring in a developer from one of our managed package product teams to add capabilities that their team needs, it’s really easy to ramp people up on Python. It’s great for adding these quick units of work. It’s just a well suited ecosystem for what we need to do.

Josh Birk:
Gotcha. And the person who is kind of being able to leverage Python outside of the open source sprints and being able to kind of contribute back to the project itself, does knowing Python give you any additional powers with CumulusCI? Does it lend in the usage of it as well?

David Reed:
Definitely. Now I should caveat that we think of CumulusCI as a low code tool within the low code ecosystem across Salesforce and most products can satisfy their needs with just the out of the box tooling and don’t need to write any Python at all. But we also find that the universe of use cases that our end users have found is enormous, and some of those folks have needs to automate things on the platform or off the platform that we’ve never even thought of, which I always find really exciting. And those folks can help serve their needs by writing 20 lines or 50 lines of Python to add a new unit of automation.

Josh Birk:
Got it.

David Reed:
And hopefully some of them will then contribute that automation back so that other folks who have the same need can get it out of the box in the future.

Josh Birk:
I always like to give Python this shout out because, and it came up with my conversation with Jason Lance, it’s like Python is so readable. And so it’s like, especially if you’re, I don’t want to say scripting something, but if you’re describing a flow of verbs and nouns, its syntax is so human readable and it kind of insists upon that formatting, right? So if you’re doing something like this, especially going back to your portable methodology, Python’s a really good language of choice.

David Reed:
It is. It’s accessible. And one of the values that we try to bring into all the tools that we build is making them accessible in the sense that people who are trying to solve different problems than us and come from a different background or a different road than us can still take up the tools that we’ve built and remix them and reuse them to suit their needs and capabilities.

Josh Birk:
Gotcha. Very, very nice. Now, I want to ping back to what you were just describing just a second ago. You were mentioning that there were these sort of surprising solutions that you didn’t think would be in the ecosystem. What are some examples of weird or interesting things that people have solved with CumulusCI?

David Reed:
Yeah. Well, one of the things that surprised me actually that I’ll call out that folks have found a ton of value in, in ways that I didn’t expect, is robot framework, which is our user interface testing integration, and also our data loading solution. And what I’ve seen in the community is folks who might not need or want the full CumulusCI vision, maybe they’re not building a product, for example, or they’re not ready to move to scratch org development yet. But those individual capabilities that I see as part of our suite, they can pull out and apply as a huge component of their overall implementation. What they’re doing is scripting a browser to walk through, to click through, a UI and either run tests or actually perform setup through that venue. Or if they’re taking our data loading, which we see as a way to seed scratch orgs, and using it instead for something like a data migration or a complex transformation project.

Josh Birk:
Now, let’s walk through some of the vision slash ecosystem of CumulusCI, because there are a lot of different working parts to it. For instance, you had mentioned data loading, but that’s even distinct from snowfakery, which we had Paul on the podcast a couple of episodes ago. Those are two different tools, right?

David Reed:
They are, and they serve slightly different use cases. Snowfakery is an incredible solution for folks that need to load any volume of fake data. I think it’s particularly great for things like high data volume testing, but also for regulated industries, where your product work might contain PII and your test data absolutely must not.

Josh Birk:
Gotcha.

David Reed:
But there’s other situations where you might want to sit down as a user and say, “I’m going to build out a representative test data set for my product that I create hands on in my org, and I just want to replicate that data set.”

Josh Birk:
Yeah.

David Reed:
“And I want it to be the same every time.”

Josh Birk:
Yeah.

David Reed:
“Not synthetic fake data.” We can serve that use case, too, by just pulling out all those interconnected records and reloading them in exactly the same form in some other org.

Josh Birk:
Gotcha.

David Reed:
That both of those use cases get covered.

Josh Birk:
Nice. Are there other satellite projects which are kind of standalone but work really, really well with CumulusCI that you want to give a shout out to?

David Reed:
Oh, that’s a great question.

Josh Birk:
Or is there too many to list?

David Reed:
I don’t think there’s actually an ecosystem of independent tools other than snowfakery that work with CumulusCI.

Josh Birk:
Gotcha. Gotcha. Let’s bring that one level higher, because we’ve been mentioning like scratch orgs and kind of where we’re org centric and where we’re not. Tell me about how to use CumulusCI most efficiently, starting from what should I consider from a source control point of view down to deployment?

David Reed:
Here’s the pitch that I usually make for those practices?

Josh Birk:
Okay.

David Reed:
Cause there’s people at many, many different points across the Salesforce ecosystem on the spectrum of work based development to source based development and everywhere in between.

Josh Birk:
Right.

David Reed:
So, my pitch is if you’re already using source control or scratch orgs or both, CumulusCI can add tooling to enhance the value that you’re already getting from those software development practices.

Josh Birk:
Got it.

David Reed:
If you’re not already using source control and scratch orgs, CumulusCI can give you some tools that will help you make that transition and it can also make sure that you get the maximum value out of those development practices, right out of the gate.

Josh Birk:
Got it.

David Reed:
Say for example, you’re an end user, you’re not building a product for distribution, you’re building one org, and your development process is based on sandboxes. A very common set of issues in that sphere is managing drift between environments where your sandboxes are no longer representative of each other or of production and managing test data. Both of those problems can be addressed by adding CumulusCI automation and source control together to that ecosystem while still retaining the sandbox and deploying from sandbox to sandbox through source control rather than through change sets. So you don’t have to do a clean break. You can sort of incrementally add some of these practices, and then as you add them, you get a platform where you can start graduating up to automated deployments, and then to scratch orgs. And then if you want to, potentially even to packaging, using unlocked packaging for that end user situation.

Josh Birk:
Got it. Do you have any advice for people who might need to review their current process and then look at layering CumulusCI into it?

David Reed:
I think that one trap that organizations sometimes fall into is assuming that the current process that they have is the only one that works or the only one that will satisfy their compliance objectives. And I think that that’s usually not the case. Of course, in highly regulated industries, it’s a little more constrained. But I think it’s incredibly valuable for organizations that are doing that review to spend some time in the community learning about what other orgs in and out of their sector are doing to be effective in SDLC and in deployment change management, because CumulusCI is far from the only tool in that sphere, of course, and there’s a lot of valuable cross-pollination that can happen in terms of both practice and tools that can remix effectively to build a modern, compliant, effective pipeline for any industry.

Josh Birk:
Got it. Okay. So going a little bit down the road from CumulusCI, what is PMM and what does it do for people?

David Reed:
Program management module, PMM, is an open source managed package that’s built by salesforce.org and it works with the Nonprofit Success Pack, although it does not require NPSP, it can also be used independently, and provides capabilities for organizations in the nonprofit sector that manage programs, including things like real world human services programs, where folks are coming in the door and attending classes. So it gives you a data model, a schema, and it also gives you a really nice user experience as a service provider to track and measure and report on those objectives.

Josh Birk:
Got it. And let’s level set a few nouns that have come up a couple of times. Give me the elevator pitch for the NPSP itself.

David Reed:
Yeah. The Nonprofit Success Pack is a customization layer for Salesforce that makes over the CRM to suit the specific needs of nonprofits around tasks like long term management of relationships with key constituents, accepting donations, including major gifts, pledges, in-kind gifts, and all of those other facets that are critical to the nonprofit world, and performing outreach, managing campaigns and things like that, that further those relationships with your key funders and other constituents.

Josh Birk:
Gotcha. And tell me a little bit more about the open source sprints and when can we see the next one?

David Reed:
The open source sprints are a .work program that brings together a community to work on projects that are important to them in the nonprofit and education spheres and that build on top of Salesforce products like NPSP and IDA. They usually happen about three times a year, and at the sprints we provide tooling and training to help our participants pursue self-organized projects that they’re interested in and then contribute those projects back to the open ecosystem.

Josh Birk:
Got it. And to make it a hundred percent clear, open ecosystem, everything you’re describing is open source and freely available online for people to tinker with.

David Reed:
That’s right. Not every single product from .org is open source, but many of our flagships are, including the entire CumulusCI suite, Nonprofit Success Pack, IDA, PMM, and Outbound Funds, which I think is a key success story as a project that originated within the community and then became an official Salesforce product.

Josh Birk:
I have not heard of that last one. Tell me a little bit more about it.

David Reed:
Yeah. Outbound Funds Module, it’s another module that sits on top of the Nonprofit Success Pack, but can also be used independently. It’s designed for organizations that make outgoing grants or disbursements of funds and it originated within the salesforce.org open source commons and open source sprint communities. It was developed for some time as a community project and ultimately was contributed by the community back to Salesforce. We took ownership of it.

Josh Birk:
Nice.

David Reed:
And now have a team maintaining and building that product as the foundation for other .org products.

Josh Birk:
Nice. That is awesome. So there might not be adequate answer to this question, but is there anything on the roadmap, like something that’s coming down the pipe for CumulusCI that you want to tell people

David Reed:
About? Oh, we have lots of really exciting plans. Do I have to say safe harbor for an open source project? Safe harbor?

Josh Birk:
You know, I don’t have the [inaudible 00:31:37] aside on the podcast. So I don’t know, but we’ll put the [inaudible 00:31:42] in there anyway.

David Reed:
I’ll definitely add the safe harbor aside here, but yeah, we have lots of really exciting plans for where we want to take CumulusCI. One that I’ll mention is, we have a suite of functionality we call Metadata ETL in CumulusCI.

Josh Birk:
Okay.

David Reed:
Which lets you do surgical safe changes to an org for things like adding a pick list value to an existing pick list or putting a field on an existing page layout in a non-destructive way.

Josh Birk:
Okay. Got it.

David Reed:
And one of the goals that we have for the future is not only adding lots more to the Metadata ETL tool suite, but also building out the user experience of Metadata ETL, so that it’s something we can use and our community and other ISVs can also use to deliver configuration for their products to customers and throw away those hundred page configuration guides that end users have to execute, or even that internal deployment managers have to execute after you install a new product or a new version of your product.

Josh Birk:
Got it. Nice, nice. And where can people learn more about all this stuff?

David Reed:
The best place to start is Trailhead. If you go to Trailhead and find “Build applications with CumulusCI,” we’ll walk you over the course of six modules through getting all the tooling set up, all the way to the point where you build a fully automated managed package on top of the Nonprofit Success Pack.

Josh Birk:
And that’s our show. Now, before we go, I did ask [inaudible 00:33:09] for David’s favorite non-technical hobby, and like so many of us the pandemic has changed that tune.

David Reed:
Oh, great question. Well, like a lot of people, I think my hobbies have changed significantly over the last two years due to…

Josh Birk:
Sure. Yeah.

David Reed:
All these other factors. Lately, my top non-technical hobby has been gardening. I recently bought a house and I’ve really been enjoying planting and caring for my garden.

Josh Birk:
I want to thank David for the great conversation and information. And as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again, everybody, and I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.