Salesforce and DevOps Part 5 - Future and wish list

OK, now that we've gone through what I believe to be good and not so good about DX and about DevOps in general (when it comes to Salesforce, that is), I think it's time to wrap the series up.

For this purpose, I'll try to keep the series finale shorter and lighter than the previous posts and will focus only on what I see and what I want to see for the future of working with the DevOps culture in Salesforce implementations.

Future of Salesforce and DevOps, as I see it

• I believe that the amount of people embracing the culture and the percentage of implementations that adopt it will certainly grow as the technology evolves (Salesforce DX and otherwise, even outside of Salesforce)
• In the not so distant future (hopefully), the Metadata API completeness (and robustness) will be almost there, allowing improved and more common use of DX globally
• When unlocked packages and "org shape" features become GA and robust, there will be a big growth in the ease of DX adoption
• As the possibilities grow and the technology evolves, there will be a lot of change and work opportunities, as most companies with older methods of delivering will begin to move fast to the new ones (DX and packages)
• Along with good work opportunities, there will be a lot of tough work coming to address the gaps between the previous processes and the new
• There will be a shift of the common ways of working with Salesforce, moving more and more towards automation and control. Hopefully, this will translate into faster, more responsible and more secure implementations, as DevOps adoption continues to grow

Wish list

• I reiterate that I really hope that Metadata API completeness comes our way really soon
• I'd really like to see the technology behind profiles get updated. As I mentioned it in the previous post, I'd really love to see the capability of using permission set groups (profile-like feature based on permission set tech) instead of the old fashioned profiles
• I'd like to see the developer experience get better for functional people, not only devs. Maybe make the UIs nicer and less dependent on IDEs, to increase adoption of source control and automation? I know that there are some ideas out there, some paid and/or external tools that help with this and at least one app being currently worked on internally that addresses this (through some contacts on the inside, of course!). I guess I just want to see Salesforce openly acknowledging this and releasing one or many of their own, soon and for everyone
• Can we please get "sandbox-like" scratch orgs? I mentioned them previously as well, but scratch orgs that would come with metadata (and maybe data) from production or from a sandbox, and that you could interact with using push and pull commands, create and kill programatically and so on would be very cool and useful. This will also potentially help with problems related to managed package dependencies
• Better performance! Especially pushing changes and creating package versions
• Flexibility on making Dev hubs separate from production orgs somehow
• Get better out of the box features for monitoring, with better UIs and with which we can interact in order to act on alerts that can be configured and embedded in DevOps processes
• Better and increased adoption of test automation, making it more trustworthy and taking us closer to the dream of a fully automated pipeline
• As all of this happens, DevOps culture hopefully becomes mainstream in the Salesforce world, making the selling process of it a lot easier and less worrisome, allowing for projects to have the right resources budgeted for the right level of support needed
• All implementations will, at the very least, have a level of source control! No matter how small and easy they are. For this, can Salesforce eventually provide some automatic ways to put metadata into Git servers, perhaps? I'm talking one-button, straight from the UI stuff (on prod or sandboxes, everywhere!). This will also make on-boarding of new projects into DX a lot easier, among many other benefits

Long shot: decoupling data from metadata implementations!

It might be a long shot, but I wanted to create a section apart from the rest to highlight this one. I'd really like to see Salesforce creating a way to decouple the data storage from the actual implementations of the metadata. 

I think of it as making Salesforce work a bit more like modularisation and virtualisation works on AWS, Azure and the like. By this, I mean that you could kill the whole implementation in scratch orgs, sandboxes and even production orgs, but keep the data stored independently (like an EBS volume on AWS), so you can link it with new implementations (like an EC2 instance, on AWS), as they get spun up.

With this feature, you could have different data stores (and probably file stores, while we're asking) for testing purposes, that you can link to different testing environments and proper stores for production environments. This, to me, would be extremely powerful and will make deployments and rollbacks (specially rollbacks!) easier to achieve, getting us a lot closer to the fully automated pipeline dream!

This could also open a whole new world of API and microservice versioning capabilities, ways of creating and managing apps, creation and managing of different communities for single customers and so on. Sounds crazy, I know, but it's a wish list in the end and I would get behind it, really fast!

Of course, this will have the following considerations, at the very least:

• Making it very easy to configure the linkage between data and implementation will be tricky and will probably need something like a Salesforce admin console as an independent thing from the production org (or orgs, as this could be made to handle multiple)
• They'd need to be very careful on linking this feature with user management, sharing and security altogether
• There will be a need to automate the linking and delinking processes, so we can leverage our CI/CD tools to use them. I'm thinking some metadata or JSON config files that we can keep in source control and some API to use them, for example (maybe adopt some provisioning and infrastructure as code principles to achieve this?)
• It would be key to guarantee that the changes in the data model are managed and propagated to the data stores in an intuitive and straightforward way. This will help us avoid linking stores that don't support the implementations and vice versa
• They'd need to be very careful not to over complicate this architecture, so that it needs excessive maintenance

Things that make me think this is possible:

• The evolution of external objects and Salesforce Connect: with OData and custom adapters now accepting read/write capabilities for a little while, they could potentially be taken to the next level to allow this. I heard a rumour once that there is a feature in the works to enable support of external data storage for standard objects in a similar way as it works for external objects. This could also help in achieving the decoupling of data and implementation
• Heroku Salesforce connect: it could be a good idea for heroku connect to be extended to allow support for killing production and testing environments, while keeping the data decoupled
• Mulesoft acquisition: with the microservice and API led architecture that Mulesoft empowers, Salesforce could do really cool things internally, making it work for this major wish list item
• Scratch orgs and unlocked packages, of course, could be used for this quite well and the CLI will be key going forwards

And that's a wrap. Thanks for sticking with me all the way to the end of the series. I hope it has been helpful and enjoyable. At the very least, I'll be really happy if you've learned something, even if it is that I'm completely crazy!

See you in the next post.

Ivan