Vivek Chalwa Headshot Vivek Chalwa is a Principal ISV Platform Expert here at Salesforce. Today I’m sitting down with him to talk about second-generation packaging and what it means for developers. We also get into how 2GP connects to things like declarative packing configuration, Apex, and orgs.

Vivek has a strong evangelistic angle to him and he even made his way into the Salesforce ecosystem by getting involved in the developer community and eventually becoming a developer group leader. Tune in to hear more from Vivek on the features of 2GP, how it works with your source control and what’s on the roadmap with it.

Show Highlights

  • Why Vivek started off being a developer group leader.
  • How he came to actually work for Salesforce.
  • What is 2GP and how it is different from 1GP.
  • How declarative packaging configuration works with 2GP.
  • How all of this helps with structuring solutions.
  • How 2GP pairs with SalesforceDX and source-centric development.
  • The benefits of flexible versioning and how it works with 2 GP.
  • How package bundles will work.

Links

Episode Transcript

Vivek Chalwa: She’s been great because I’ve always enjoyed occupying that kind of evangelist role where you are teaching others about what you’ve learned.

Josh Birk: That is the Vivek Chalwa, a principal ISV platform expert here at Salesforce. 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. Today, we sit down and talk to Vivek about a wide variety of things, including a lot about second-generation packaging and what it means for developers. But we start with his early years, which after an attempt in acting, he got into Microsoft and then slowly transitioned into Salesforce.

Vivek Chalwa: I had been interested in Salesforce, mostly from the platform side from force.com, since 2009, but didn’t really quite understand how valuable the overall platform could be, especially with sales and service cloud, until I was in that director of technology role. And we were considering Salesforce for the call center at that company. Now, we didn’t go with Salesforce, or they didn’t go, but my choice was to use Salesforce, but the account exec was so kind and kept in touch with me. And she kept sending me to different Salesforce events all over Southern California. And so I just kept learning more and more about Salesforce, kind of from the customer and the admin side. I would hear a lot of some of the early podcasts and web webinars and things that people would do from the dev evangelism team back then.
And the opportunity of being a Salesforce professional, what we now call it, the Salesforce economy and how much opportunity is there. That drum beat has been sounded since, since 2010, at least. And having lived through one IT gold rush in the mid nineties, I saw something in Salesforce that felt a lot like that. I made a decision between 2011, 2012, to completely pivot my career and focus on Salesforce. So I spent a lot of time learning as much as I can. And this was at a time when we didn’t have Trailhead. So folks like Dan Appleman and his books were a big help and kind of snowballed from there.

Josh Birk: Well, that’s interesting. First of all, I think it’s interesting you said you’ve always kind of had this evangelists tend to this angle to you and yet one of the ways we got you into the Salesforce ecosystem was by evangelizing to you. So win-win.

Vivek Chalwa: Exactly, exactly. And so on that point, one of my favorite parts about the Salesforce ecosystem in general is the community. I mean, it is the secret sauce of Salesforce success because look at what the AE did. We weren’t going to buy. I was not in a position to help her hit her numbers in any way in that year. But she saw that I was interested and wanted to help. And then from there I started going to Salesforce user group meetups down here in San Diego, the great folks like Rhonda Ross and Alana Saunders and all the work that they did and started to see this community of people who were so interested in helping each other. And even as I was kind of retooling, I mean, I’m very technical, have a very technical background, been a developer, architect. I know my stuff. But anytime you go from one platform to another, there’s always learning curve. And especially, my biggest learning curve was just understanding CRM.
There’s a lot of developers, we enter the Salesforce ecosystem and sit us down in front of apex or lightning web components and we can figure that out in no time. But if you don’t have the context as to what the actual use case for CRM is or service or anything like that, you’re behind. And getting to talk and learn from people in the community was great. And then went to my first developer meetup in 2013 and loved it so much. I said, “Hey, how can I start this in San Diego?” So I started a developer group down here. So I’ve seen firsthand just how gracious and giving and supportive this community is. And at every stage that I’ve tried to learn and tried to go up to the next level, it’s been great to have people to help, to help me do that and to help the people around me do the same. And it’s just, I haven’t seen any other technical ecosystem that is this open and this friendly.

Josh Birk: Yeah. It came up in a previous interview and the line was something like, they went to a user group meeting and they said something. And then somebody pinged them back and like, “Hey, I’ll help you with X, Y, and Z.” And they’re like, “Who are you?” Who does this kind of thing? And it’s, well, that’s the way our community works. On that CRM front, quick anecdote, if I’m remembering correctly. When I interviewed at Model Metrics with my good friend and several times boss, Rick Karlberg, I think one of his questions was something along the lines of, what’s your familiarity with CRM products? And my answer was, what’s CRM? I have no idea what you’re talking about here, pal. So I was going to paint on the developer group thing. That’s fascinating that you … well why did you want to be a developer group leader? So you actually started that developer group and then how long did that run before we stole you up to the mothership?

Vivek Chalwa: So the first group I went to was up in Los Angeles. I think it was the Salesforce Mobile Week or something. It was right when the mobile SDK was first launched. And so I met this great guy, Nathan Pepper. So shout out to Nathan. One of the most unique characters I’ve ever met and just loved the guy and, like I said, was so enthralled by that experience and the comradery there. And Nathan introduced me to April and then April Nassi from back in the day. And I started, I think within a couple months of that, I had my first developer group meetup down here in San Diego. And one of the first people that came to that meetup was a great guy named Tyler Mowbray and he became my co-organizer.
So right from the start, I had great support there. And so we kept running that and we do something unique in San Diego. We do meetups every two week period. It is a standing meetup. We call it the technical knowledge share, TKs. I mean, as any developer user group leader would know, coming up with content is hard. It’s hard, it’s stressful. It is a labor of love to lead any sort of user group. And I didn’t want the scary cliff of, “Oh my gosh can I get a guest? Can I get the location?” I didn’t want that to stop us from meeting regularly, especially at the lack of content. So this was the thought, if I can get a regular room, if I can get a regular space, then we’re just going to meet every two weeks.
And whoever shows up, we’re going to bring the content. Whoever shows up that day brings the content. And what I’ve found is that we would get lots of different types of people. We would get architects, we would get developers, we get admins who are developer curious. We get people who are outside of the ecosystem and just want to figure it out, or they’re changing jobs or they want to change jobs. And each one of those cohorts comes with different questions and as new products are announced or released. What’s up with this or what’s up with that? Or I ran into this really tricky problem today, how would you handle that? And so for an admin who’s developer curious to come in, and maybe there’s an architect in the room that day, and for there to be an interchange, A, it’s a fantastic opportunity to solve a problem.
But B, it’s a great way for people to learn from each other. And it has been such a gift. This type of interaction is just great. And we have people that are regulars for years and years. To finally answer your question, how long have I done that, when did Salesforce steal me away? So in 2015, I was very proud to have been named a Salesforce MVP. That was really awesome. And then a month after that, I got the job offer Salesforce. So lost the MVP status and had to step back from running the developer group. But my good friend, Tyler, took it over. Now he’s actually run it more years than I have.

Josh Birk: Nice. Well, I want to thank you for all your work in the community. Today I want to talk to you a little bit more about your day job and specifically when you’re working with our partners on 2GP or second-generation and packaging, as a topic. First of all, what is the elevator pitch for 2GP?

Vivek Chalwa: The elevator pitch for 2GP is that, if you are going to package up customizations, whether you’re a customer or you’re a partner, packaging our customizations is something that’s very special and unique to Salesforce. So with 2GP, it’s a source driven, modern way of packaging your customizations in ways that you can have multiple packages with the same namespace. If you’re doing managed packages, you can have a special things. With unlocked packages, you can have org dependent packages. So it’s essentially an evolution of the standing packaging model that’s used by ISB and customers in terms of managing unmanaged packages.

Josh Birk: Gotcha. Okay. Well, let’s dive into some of those distinctions and as we’re diving into some of these, maybe we’ll try to compare it back to what we know as 1GP and things like that. But so tell me what declarative package configuration is and how does that work in 2GP?

Vivek Chalwa: Sure. So when I say it’s source driven packaging, one of the key parts of that is the definition of what’s in the package. In the previous world of 1GP, the definition of what’s in a package is trapped inside of the packaging org. It’s trapped inside the org that you do the packaging. So, just to set some context with terms, with 1GP, there is this concept of the packaging org. Managed packages are packages that can only be created in DE orgs, developer edition orgs, for example. Unmanaged packages can be created in different types of orgs, but in either of those, the org in which a set of metadata components is defined as a package. And then where there’s a UI to click a button to say, upload that package so that it gets into the Salesforce packaging and distribution backend system.
All of that stuff is org driven. It’s org based. It happens in the packaging orgs. With 2GP, there is no packaging org. Not for managed, not for unlocked. It’s all source driven. What that means is that there now needs to be a new way to configure certain things, like what’s the name of the package or what version number is about to be uploaded? What are the dependencies, things like that. And all of that is now found right inside of the same SFDX project [inaudible 00:12:02] file, that anyone who’s familiar with Salesforce DX based development is used to. If you’ve got a directory on your computer and there’s an SFDX project [inaudible 00:12:15] file in it, that directory is a Salesforce DX project directory. So you define your package properties right in that SFDX project [inaudible 00:12:26] file.
And what that means is that you can now commit stage and commit that to get. And so you can track it in source control. So instead of having the things that make your package exist in an org where there’s no definitive way of knowing if someone’s going to flip a switch and change the name or something about it, you can’t see the history of any of that, with it all externalized in this declarative packaging model, all of those settings and all of the metadata itself, is going to go into the package. All of it is externalized as source and can be tracked in a version control system.

Josh Birk: Yeah. I mean, I was going to say that very clearly that lines up closer with the way Salesforce DX development kind of has a fault compared to the 1GP where you’re trying to talk to the org. Does it also help in, and I think this has come up in some of the other episodes, does it help in structuring your solutions to a certain extent? If you need to make pieces of code more distinct for things like separations of concern, is this a friendlier model for that?

Vivek Chalwa: It can. So when you’re talking about separation concerns, what you make me think of there is possibly separating packages. Using packages as-

Josh Birk: Intentional dependencies kind of thing.

Vivek Chalwa: Yeah. Right. And this is something with 2GP, it’s so much easier to do that because you can keep all of these different packages that you might want to create. You can keep them in the same namespace. So let’s just stick with the separation of concerns example. In 1GP, if I wanted to create a base package that had, let’s say, my core schema and then a bunch of utility classes, maybe I’m using the financial forces library, FF Lib, which for ISB’s that’s a really very common open source library of apex that the developers will add to their packages. So maybe there’s that’s in the core package or the base package. And then there’s the schema and all that. And then I create extension packages where maybe I’ll do specific features.
With 1GP, a couple problems exist. First, those extension packages would have to have different namespaces because there’s a one namespace per package restriction in 1GP. And then not only that, those extension packages for them to call any of the apex that is in the base package, those apex classes and methods have to be marked as global. Essentially, when you’re developing the base package, you have to make a public API that the eventual subscriber who installs this package, that they would have the ability to call as well. When that’s not your intent, you just want your extension package to be able to call the same, this logic. And this can cause problems because once you create something that’s global, you can’t remove. You can’t change it because customers or subscribers might create their own integrations based on that. The number one rule of creating package upgrades is don’t break the customer.
And so there’s restrictions on changing things that you’ve marked as global. And so it’s a big deal to be stuck in that model with 1GP. 2GP throws all that out the door. Because with 2GP, you can create that base and extension packages. They can be in the same namespace and you can use a specialized annotation inside of apex called namespace accessible, which means that a class in that base package that’s just marked as public, but also annotated as namespace accessible, that class can be accessed by any other package within the same namespace. So I’m not creating a global API that anyone can use. I’m creating a specific namespace based API that only my other packages can use.

Josh Birk: Nice. Nice. Okay. So, more flexible namespace, more flexible dependencies and things like that. I just kind of see how all of this is sort of lining up with the Salesforce DX philosophy of coding and source control. Does 2GP also change up the game, because versioning and commit history and stuff like that is kind of a huge thing when you’re doing this sort of, get style development. Does 2GP also change up the game for that?

Vivek Chalwa: So I’m very glad you asked that because, if we think about the features of 2GP that are the hot ones. Multiple packages, same namespace. That is hands down the thing that everybody loves. If you had to say, what’s the best thing about 2GP, that would usually come first. I think that might not be the best feature, actually. I think, I mean, look, it’s great. Don’t get me wrong. It really is great. But I think one of the most powerful features of 2GP is the flexible versioning model that 2GP uses versus 1GP. So to make this make sense, let’s think about what happens in 1GP, first of all. This is relevant sort of specific to manage packages, by the way. Just want to clarify.
So in 1GP, when I’m building a managed package, essentially, you get metadata components like your apex classes or your objects. You get all that metadata and configured in the org. Then you say that, okay, I want this to be in the package and you select identify all the metadata that you want to be in that package. The thing that actually turns what you’ve done in that org into a package that can be installed, that’s the package upload process. And when you upload a package, you have a choice in 1GP. You can upload it as a beta package, or you can upload it as a released package. So when you’re doing this, when you’re doing an upload and then let’s see, we upload version 1.0 and that’s a managed released, and then you and I, we’re going to work on that.
And so we do. Maybe you work on 1.1 while I’m trying to work on 1.2. We can’t really get in each other’s way, because whatever you’re doing for 1.1, when I’m going to add the stuff that goes into 1.2, I need to add it on top of whatever you’re doing. And we’re still doing beta packages so everything’s cool. Well, let’s say the a week we get to version 2.0. And we said, okay, this is what we want to release. And we upload a managed, released package. Now let’s say that we haven’t sent it to customers or anything, nobody’s installed it yet, but it’s been uploaded as managed released. Let’s say that that feature that I was working on, there was something really wrong with it. I actually made a big mistake or there was something I shouldn’t add, or I made it a dependency that shouldn’t have been there that maybe would shrink the possible list of subscribers because not everybody has this certain feature activated, maybe I added a Tableau CRM component or something.
So only subscribers that had Tableau CRM activated would be able to install the package. Well, that’s a big mistake. We don’t want that in an extension package. But now, we uploaded it as managed release. There’s nothing we can do except call support, have them roll back to beta and then remove the things. It’s challenging to to make that happen. 2GP handles is totally different. With 2GP, first of all, you and I, we could both be building out in completely different directions. And we could be building packages that are marked as released, but we don’t have to release those to customers. We can always try them out. We can install them in different sandboxes to get feedback from customers and we can upgrade them because we’re running them as released.
And if we don’t like where we’ve ended up, or if we want to kind of merge our changes in source, as long as whatever the next version that we build points back to whatever version that our customers have installed, then we can build a package like that and it can be upgraded. And so what we’re doing is, we’re basically selectively choosing the ancestors of the packages that we’re building. Now, this is really hard to visualize. For anybody listening, if you’re lost. I don’t blame you. To be honest with you, when I first started talking about this flexible versioning as a feature, it was one slide from the PM with three bullet points. And I really didn’t get it. I tried to drop it off of each presentation I did because it didn’t make any sense to me.
Gotcha. There’s a series of videos that put out called 2GB deep dive features and use cases. In one of them, we actually talk about this flexible versioning. And I take people on a visual tour of what I just talked through. And I encourage anybody to watch that video because once you understand it, it’s one of the most powerful features of 2TGP. And the reason for that is because it just lets teams be more flexible.
If we just ignored all of the picture that was trying to paint, I could simplify that by saying, if we’re using 2GP, you can go off and build whatever you want in your direction. I can go and build whatever I want in my direction. And whenever we decide to do a source merge of your best ideas and my best ideas, we can create a package that will point to whatever our current public customer-facing package is and make that the ancestor. And basically make that the upgrade path to this new package we’re building. And then you can abandon your code. I can abandon my code and we can start the whole process again. That is something that is not possible with 1GP.

Josh Birk: With 1GP. And you kind of have me reframing my next question. Because I think you, we keep kind of cutting to this point. The original question was something along the lines of, what’s a tipping point for a development team to really strongly consider 2GP, but it really sounds like a lot of the advantages are, is your development team using source control, source oriented development and or are you in this get style development cycle and if you’re doing that, is there any reason not to use 2GP? I mean, they just seem like they sync so well together.

Vivek Chalwa: So that’s a very good question. I would actually take it a step farther specifically for ISB’s. If you’re an ISB, any net new packages really should be 2GP. There is no reason not to. I think the one roadblock might be is, if you’re a longstanding ISB and you’ve got a 1GP package out in the market and all of your efforts on your development team are based on supporting that and enhancing that, for right now, we don’t have an ability to migrate their 1GP package to 2GP. Package migration, as a feature for 2GP is coming and it’s being worked on. It is the priority of the packaging team right now. But this is something that we’re here in first half of 2020. This is something that’s safe harbor, not going to be GA until, say, winter 23. So 12 to 18 months.

Josh Birk: Got it. Cool.

Vivek Chalwa: So I could understand if your whole development team is focused on building or maintaining your 1GP packages. It can be an extra lift to transition to 2GP, but it really is worth it. Even if all you’re doing is for your new packages, maybe you’re creating an extension package, there’s 2GPs have no problem being extension packages to 1GP. It works great that way. But that team would have to have adopted Salesforce DX in order to be comfortable with the 2GP model. So if they haven’t done that, I could understand why they might want to wait. But having said that, there are a lot of advantages to Salesforce DX based development. And a lot of answers for 2GP.
So I think it’s worth it, but it’s a conversation that they would have to have with the product owners. Whoever’s running dev ops and whoever’s doing development. They need to get on the same page about that. Now that’s the partner who’s had a 1GP in market for awhile. If you are a brand new partner, I want to be very clear about this. Brand new partner, there is no reason why you should be using 1GP. If you have a 1GP app and you haven’t put it through security review yet, you should think strongly about changing to 2GP. And like I said, if you’re an existing partner with an existing 1GP app, if you want to make new extension packages, strongly consider making those 2GP.

Josh Birk: Got it. So you, you touched on the roadmap a little bit there in your video series. You mentioned something else that I think is coming up with a roadmap. What are packaged bundles and when can we get access to them?

Vivek Chalwa: So packaged bundles are going to be a mechanism to install multiple packages with a single install URL. That’s a simple way of looking at it. We talked about one of the benefits of 2GP being that it’s very easy to have multiple packages in the same namespace. You have that great cross package communication with namespace accessible apex and all that. The challenge is, if you were to take your solution and break it into four packages, as an example, those are four individual package installs that have to happen in order to install your solution. Where if you were just using one monolithic package, it’s just one install. And so packaged bundles addresses that by wrapping up all of those. Now I want to be clear, this is all very safe harbor because we have shifted our focus away from delivering package bundles so that we can make sure package migration happens first.
The 1GP to 2GP migration is something that adds newer partners or partners who are building newer apps, as they have embraced 2GP. And as kind of the word’s getting out on the powerful features and the awesomeness of flexible versioning and all of that stuff. It’s making existing partners want to have 2GP sooner, rather than later. And so we’ve decided to shift our focus, to make migration happen as soon as possible. And so packaged bundles will happen, will come after migration.

Josh Birk: Got it. That sounds like an excellent plan. Now we will link the show notes to those wonderful videos that you put together. Are there any other resources you would recommend?

Vivek Chalwa: Yeah. And I’ll have to add this. So I’ve created a bunch of trail mixes where we’ve got, there’s trail mix for the deep dive. Right now there’s, as you said, the features and use cases videos. We’re working on a development and dev ops series of videos as well. But that’s all in its own trail mix. I’ve also created some other trail mixes where all of the relevant documentation to 2GP and the relevant partner community groups or trailblazer community groups, because 2GP is more than just managed 2GP. There’s also unlocked packages, which are a wonderful tool for customers to use. All of this are in these different trail mixes. So I’ll give you the whole list of trail mixes. And if you can put those out, that’d be fantastic.

Josh Birk: And that’s our show. Now we will have those links for you in the show notes for you to check out later. Now I did ask after Vivek’s favorite non-technical hobby, and it turns out that it’s one that’s fairly common on the show, but then, well, you’ll see what happens.

Vivek Chalwa: I really do like hanging out with my wife. I mean, I love video games too, by the way. But I play a lot of video games while in the same room as my wife so I’m not really sure which is which. But no, I love gaming. I used to be a hardcore PC gamer and gave all that up. And, but now my tablet, I enjoy Genshin Impact when I can. Black Desert Mobile. Those are the two games that take a lot of my time.

Josh Birk: What’s your adventure in Genshin.

Vivek Chalwa: It’s only AR 44. I’m trying to stay away from AR 45 because … Well, so, I run Barbara as-

Josh Birk: I know exactly where you going, go, go.

Vivek Chalwa: I run her as a battle mage along with a C6 fischl. And with fischl, so I put the bow, I forget the name of it. I don’t know if it’s favonius or something, but I put the bow on fischl that essentially whenever-

Josh Birk: Now, faithful listeners, your ears are not failing you. I actually struggled a lot with what to do with this audio. Vivek and I basically went on to geek out about Genshin Impact for about another four or five minutes. And so if I left the entirety of that audio in, us talking about Genshin would be about 10% of the total interview. So maybe that will be exposed at some point in a future episode when we do some outtakes and things like that. But needless to say, that both he and I are huge fans of the game. Now I want to thank Vivek for this great conversation information. And as always, I want to thank you for listening. Now, if you want to learn more about the show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes and 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.