Muselab

Today we are excited to announce an essential pivot in our platform direction. For years, we've worked toward our vision of bringing Salesforce DevOps in-line with industry DevOps practices and infrastructure. We've worked to build our platform providing the missing features needed to turn GitHub into a comprehensive, and even better, Salesforce DevOps solution than those many customers pay $300/user/month for currently. We came to an interesting discovery... much of our platform wasn't really needed if we just used GitHub more creatively. Innovating new ways to use platform features is what we've been doing on Salesforce for years! Now, seeing GitHub itself as a platform is transformative. Why pay for a Salesforce DevOps app at all (a ~$2B ecosystem with growing investment) with just GitHub at $21/user/month for Enterprise? As a result, we've decided to rebuild D2X to be the open source "platform" on GitHub's platform for Salesforce DevOps. We invite you to join us in the discussions at https://lnkd.in/g3_qRWqj

?? One of the biggest technical hurdles to overcome with scratch orgs, the Composable Delivery Model, and composable development on Salesforce in general, is how to handle dependencies as your catalog of modules grows. Inefficiencies in point-to-point solutions quickly become apparent. This is one place where CumulusCI excels with the only of its kind (for Salesforce) dynamic, recursive dependency resolution and installation. It's like magic! For example, building on NPSP (6 packages, 3 bundles of unmanaged metadata, in order) at the latest version with CumulusCI is just adding one line to the cumulusci.yml file pointing at NPSP's GitHub repo. But, magic can come at a cost of observability and predictability. Does that mean we should give up on dynamic magic? Absolutely not! It means we need to innovate better solutions to this persistent challenge in the ecosystem. We're excited to share the first preview of precisely that innovation. For now, just a screencast: https://lnkd.in/gPiht3y5 Coming soon: A massively upgraded D2X with reusable GitHub Actions workflows to make automated, hash-based snapshot management easy for anyone with 100% open source software. Oh, and vastly improved docs covering all the goodness. Curious about the Composable Delivery Model? Check out our article: https://lnkd.in/gAdKHMPR

?? The first time you set up CI/CD automation and it works is exhilarating! ?? But, don't forget to pause and consider the security implications A common need when designing optimized GitHub Actions workflows for Salesforce CI/CD is the ability to pass information between jobs. An example is the credentials for an org (scratch, sandbox, or trial) created during the build. Splitting up workflows into multiple-jobs can improve reduce build times through parallelization, enable more granular retry on failure, provide better security isolation for jobs, and integrate much better with GitHub's web user experience for Actions. Learn more about the challenges we've faced in our multi-job workflow journey and the security constraints to navigate along the way in this blog post from Jason Lantz

We've been on a mission for the last two years to identify a better development model for everyone building on Salesforce. Today, on the last day of #Dreamforce and after a compelling case for Composability presented at the Architect Keynote, we're excited to introduce the Composable Delivery Model. #ComposableDeliveryModel

? Our poll from two weeks ago confirmed a suspicion we've had that there's a lot of confusion in the community around what's actually in an sfdxAuthUrl. After a week and votes from a small sampling of the community, the results confirm our suspicion of confusion. The sfdxAuthUrl string provides anyone with it perpetual access to an Org user, even through password changes (unless the OAuth grant is revoked). They are usually used in CI/CD pipelines and developer tools, typically to access full admin users in the target org. By the way, the correct answer to the poll is #3: Full OAuth + Refresh Token. Not the winning answer! #Salesforce #Security #SalesforceDeveloper #SalesforceDevOps

? Do you know what's in your sfdxAuthUrl? The sfdxAuthUrl is a commonly used string generated by SF CLI via the command: sf org display --verbose This string can then be shared with other users or CI/CD systems to gain access to the org as the user authenticated via SF CLI's OAuth Connected App. Knowing how to build security processes around handling sfdxAuthUrls requires first knowing the risk they pose, starting with what they actually contain. To establish a baseline, please use this poll to establish your best current guess of what's contained in the sfdxAuthUrl's structure. We'll post a helpful cheatsheet once the poll is closed to help you remember and understand the security implications of sfdxAuthUrls. Option 1: OAuth ClientId + Access Token * Connected App Client Id (Consumer Key) * Org Access Token * Org Instance URL Option 2: Org Id, Access + Refresh Token * Org Id * Org Access Token * Org Refresh Token * Org Instance URL Option 3: Full OAuth + Refresh Token * Connected App Client Id (Consumer Key) * Connected App Client Secret (Consumer Secret) * Org Refresh Token * Org Instance URL Option 4: OAuth ClientId + Refresh Token * Connected App Client Id (Consumer Key) * Org Refresh Token * Org Instance URL

Headed to #Dreamforce? Don't worry, this isn't another swing by our booth post! Instead, we want to equip you with some important questions you should be asking the numerous partners you'll talk with at Dreamforce and after. We'll caution that some of these questions don't have great answers currently. But, every one of them aligns with established security best-practices around authorization and access control. As customers, you have the ability to incentivize partners who are committed to improving security practices. Or, if you're one of those partners, these are great questions to start thinking through your answers. They're all legitimate questions any enterprise CTO would ask because they're good practices. How could you improve your security processes around customer org access? https://lnkd.in/gCqHTPPP

How secure is your Salesforce DevOps process? We've discovered that many common practices across the ecosystem for setting up DevOps and CI/CD builds often violate standard security principles such as least privilege access control. The use of sfdxAuthUrls or JWT certificates in build secrets is a common culprit. But there's not an easy answer, yet. While there are some solutions to tighten security, we've discovered a gap, a missing platform to solve the problem. We're actively building that platform, as you'll learn more about in this blog post. Learn more about why and how to secure your DevOps process: https://lnkd.in/giDbxCp6

Do Scratch Org Snapshots still sound like a dream you'll find the time to get to someday, even knowing it would save you time today? We've heard great interest and excitement from Salesforce developers in using scratch org snapshots but have heard few success stories. Check out our comprehensive guide covering some of the undocumented challenges and solutions to fully automating your snapshot build pipelines. Whether using SF CLI or adding CumulusCI to the mix, we're excited to share our real-world experience from implementing snapshots into a complex package development lifecycle. https://lnkd.in/g2SCVV5e

? Are you using Scratch Org Snapshots yet? We just started on our first full implementation of Scratch Org Snapshots for an ISV client. The results are beyond impressive. In a real world use case, snapshots are able to take 57 minutes of automated installation and configuration of dependency packages down to 8 minutes. 8 minutes to create the initial snapshot and 8 minutes to create a new org from it. From a DevOps perspective, this is huge. When your builds have a valid failure, you want to be able to recreate that failure as quickly as possible to test the fix. Snapshots can also be used for developer orgs, qa orgs, demo orgs, etc. Tired of that TSO demo org that takes over an hour to spin up? Have you tried snapshots yet? Are you still facing confusion about how snapshots could fit into your workflow? Share your challenges in the comments or grab some time to talk: https:calendly.com/muselab/free