Ivan's Tech blog

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 D...

I have to admit I've been looking forward to this one, after going through the tools and usual lifecycles (and ranting about my views as well). This post is going to be dedicated to describe my experience, views and decision making process about Salesforce DX, including where and when to use it (or not). Keep in mind that this is all accurate only as of the date of the post creation (August 2018), and as far as I've used it and researched. I'll try to update this one or follow up on different posts in the future. As usual, please comment if there's something you believe I should add or update! If you want more of a detail about what DX is and some quick start instructions, there's a pretty good blog series on all things DX here: https://developer.salesforce.com/blogs/2018/02/getting-started-salesforce-dx-part-1-5.html . There's also the dev guides, of course. Let's get to it. As I mentioned lightly earlier in the series. After a long time of n...

Now that you (hopefully) read my rants on my views and the tools involved in DevOps for Salesforce, I'm going to show how a common development lifecycle works in Salesforce today. I'm going to leave this slightly agnostic to the tools, focusing more on the steps for development and releases that in my view are needed for a common Salesforce implementation. This includes DX use, I'm going to mention it here and there, but won't go into detail in this post, as it will have a dedicated one next in the series. This post covers just a single org lifecycle, as you can extrapolate to as many orgs you need by applying a flow for each. This assumes that the orgs are completely independent and that there's a valid use case for that. For some good info on determining if your company or client needs one or multiple orgs, check this article , it can probably be a bit outdated on some details, but it's a very good starting point. Let's get to it, then. First of al...

Break over, let's get back to it. This post is a continuation of the second part of my Salesforce and DevOps series . In that post, I wrote a list of the tools that apply to Salesforce in the categories that I view to be the "Dev" part of DevOps processes. In this one, I'll try my best to do the same, but for the Ops part. Again, as usual, please let me know if there are any other tools or categories you guys think I missed, happy to update. Before I begin, I have to say that a big part of what software Ops usually does doesn't apply to Salesforce. Being a managed cloud service, we can't really monitor, configure or act at all with regards to their infrastructure, overarching security of the service and their practices (by "they" I mean Salesforce as the provider). What we can do is control and operate how we run our own implementations on top of Salesforce's core platform. Let's start running through the categories. Full disclosure...

After rambling about my views for a while in the start of this series , I thought I'd take it down a couple of levels and talk about the tools that I've used or know about that are compatible with Salesforce and DevOps. This will be a long post, so I divided it in 2, one for Dev, one for Ops. But please bear with me, as it's important and will be needed for the next posts in the series and it can be useful for people as a go-to list. In that spirit, please send me info in the comments about other tools that I missed and you use and love, and I'll keep updating after checking them out. I'll break these 2 posts down into a few categories, as much for ease of reading as for highlighting the importance of each and the width that DevOps brings into any engagement. Of course, this is not a definitive list, as there are a lot of tools that do super cool things, but either I haven't used them, or they don't apply to Salesforce (usually because they're infr...