Ivan's Tech blog

UPDATE: By popular demand, I want to note before I begin that the solution described here is not necessarily the optimal for the scenario presented below. It is meant to be an example of how all these tools can coexist in case they're part of an enterprise landscape. Especially with Salesforce's acquisition of Mulesoft, this very well might end up being the case for some enterprises. Toward the bottom of the post, there's a section with a few bullet points on what the solution could look like (including serverless options, of course), but it's a long post and I can appreciate that not everyone will get there! The title says it all! In this post, I'll walk through an example of how Docker, Kafka, Mulesoft, Platform Events and IoT Cloud could work together, to create a really powerful landscape for companies with IoT use cases. I thought of writing this one because integration of different systems is one of my biggest interests (alongside DevOps). I find that st

As an architect (Salesforce and Enterprise), one of my favourite things in the world are architecture principles. Principles define the foundation for the way your teams must work and the rules you want to have set in stone (they can't be broken without extensive and clear justification). They are mandatory, but they shouldn't be adversary, they need to be an agreement, a consensus that allows everyone involved to understand how things need to be done, and more importantly, why they need to be done. They have to believe it for the whole thing to work! I googled the definition of principle and this is what came out: "a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning." I like that very much. I want to focus on the way principles serve as a foundation for a system of belief, behaviour or for a chain of reasoning. They are what you need to build upon, when creating teams of people, n

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