Why you should stop just creating code!

How many times have you started a project or joined a team where the code at production wasn’t the same at the repository? Or even worse, there’s no repository or any version control system, and you have tons of code lines that are commented on, without any explanation. After all, comments were made for comments not for “code parking”. 

 

In this post I will share some software best practices, take a look at how Salesforce has been merging these concepts to pave the way inside their platform, so you can create a better product in the end.

 

Yes, keep in mind that from now on, we will see our deliveries as small products. Not just a script that runs on a server when you do some action, or some automation that does the hard work for our users, but a product.

 

 

It’s common sense that for everything you create with code, you should have a code repository and a version control system, right? So why is something which started around 1975, still not present in modern applications?

 

When I started working with Salesforce.com, back in 2011, the platform was very permissive. What I mean by that is the fact that you could change code directly at the Production Org with developer console. At the time, I was already used to working with version control systems as a heritage from my Java background. The point was landing on Salesforce world, where the key words at that time were ‘Cloud computing’ and ‘no-software’.. Those two key words combined were used (arbitrarily) to support teams looking only for deliveries and not good software or project best practices. Many also used to have the mindset of, “if it’s not mandatory, it’s not needed” but eventually some of us started creating those ‘comment-version-tracks’, once we knew comments did not count towards code line limits. At times you would even find a class file had more ‘comments’ than real code.

 

A simple solution was to add your project code at a Git repo, even if that was not your real source of truth, at least you could have a clean code running inside your orgs. Now you could be asking yourself, “well if my repo is not my source of truth why should I have one?” The answer to that question is that any way that enables you to compare your code versions is better than none, and yes it will need a committed team to keep the code synchronized and up to date. 

 

Even as an additional step for your development process, it would be wise for a team to use a version control system rather than keeping the code in an org. Especially if you keep in mind that sometimes a bug in your code might be due to configuration than an error in your code.  Keeping all changes, code and metadata files’ versions can enable you to compare those versions or orgs to help you find out what is going on and help you to fix it.

 

How can we tie this practice inside the development process and make it part of our workflow? Keep reading to find out. 

 

 

I believe everyone has seen this image before but what does it really mean? How should you understand each of those icons, and why is the Source Control icon in the center of everything?

 

 

Let’s start reading this image from the center towards the edges. If Source Control, as we mentioned before, is not a central part of your development stream, it will not be your source of truth. But when you start applying an ALM that fits Salesforce, and take leverage from a collection of good practices, then we have our Source Control as our source of truth, and it will have a really central place in the entire process, as the image below indicates.

 

As a good software professional you always start with a plan, so you dimension what you need to do, and how you will do it. Once you have your plan defined, then it’s time to start coding, you can use your favorite IDE, or your preferred text editor. Salesforce also has their ‘go to kit’, but one thing to follow is to stop using developer’s console from Salesforce. Not because it’s bad or good, but because it limits you if you need to create or maintain a Lightning Web Component.

 

After you create your code and ensure it has at least 75% of code coverage, you can start merging your changes and deploying it to lower environments for tests. After passing your initial tests it’s time to promote your changes to environments that will also have other developers’ new changes. They could be declarative or programmatic changes, which is why it’s very important to always test in an environment where all the current code and all its changes exists together. Those environments often receive the names of SIT (system integration tests) and UAT (user acceptance test). If changes are approved and no errors are found or found and fixed, and everything works as expected, then you can collect your key user’s signoff and release your changes. The circle will follow those steps until the entire project ends, or no more change is needed.

 

Nice, but how do I get it to work? If you notice all the steps in the circle, there isn’t always a tool that will magically do the task. These are, in fact, steps defined under a modern way for Application Lifecycle Management. This in effect means that you can use combinations of tools depending on your tech stack, the tools you have available and also the ones you work better with.

 

So how can I ensure the process follows best practices and the correct order? Where can I have an overview of everything that is about to be on Salesforce? To answer some of these questions, Salesforce has initiated a Dev Ops center, as part of an open Beta. This was announced during TrailblazerDX’22. More details follow. 

 

 

At the TDX’22 it was announced that the DevOps Center would be available as a public beta for June 2022, and GA in the Fall 2022. Ok, but what is that, and how will it make everything easier?

 

 

Truth be told, change sets is something that everyone has created, at least a ‘_v2’ change set. Maybe for a missing component, maybe you forgot to add that custom label at your change list or due to some other error. It was a frustrating process for a lot of people. Going through all the trouble - manually updating your code in the version control, following all the best practices and steps for the modern application lifecycle management – is a lot of effort. Then you go for custom infrastructure to build all the automations needed and invest time configuring and creating all those components. For a second you may also think that you are good with your org developer model. But even for a small team, that is not a great improvement.

 

Well, this is where everything changes! Imagine a way that you can track changes made by a low-code developer, who has no experience with code versioning, branches, and all that pro-code talk. With that tracking you would also be able to get rid of your list of changes, since the Sandboxes with source tracking, and Scratch org, will monitor all changes you did in your org  - from the moment the org is created until you commit your changes. That looks very promising. What if I tell you that you also don’t need to create the change set and can automatically have your changes moved from one org to other until production? Alongside keeping your code and branches neat and tidy? Wow! what a change right? In summary what Salesforce did was to put together a simple, visual, and easy to use way to board almost all Salesforce DevOps scenarios, based on Modern Application Lifecycle Management, together. 

 

Now, being a precise reader, you may have noticed the ‘almost all Salesforce DevOps scenarios’ and you may be curious about what the gap is. So, the DevOps Center was released as a public beta in June 2022? Yes, this means that they are still implementing some features and integrations, as now we can connect only one source control system which is GitHub. They are planning to expand and rollout new integrations for GitLab, BitBucket for instance. Also currently it doesn’t have native integrations for a ticketing system, e.g.: for Jira. That, of course, can be handled using products from other partners that will keep tickets and work Items together. The big advantage of the DevOps Center is that it was created as a Salesforce App as well, that needs to be installed into your org. This will allow the developer team to release functionalities for this product without depending on Salesforce releases, giving more autonomy and speed.

 

It’s nice to see that Salesforce is not only creating a Modern Application Lifecycle Management culture and bringing all Salesforce professionals together to understand those concepts, but also creating the tools that will shape the use and application of these concepts inside the platform. This creates a healthy org environment, covering the low-codes and pro-codes developers as a unique team (do I feel Ohana vibes?). If the TrailblazerDX was an event not on your radar or you thought it was not for you because you don’t do pro-code, in my opinion, you should start keeping an eye on it. There are a lot of things in store for the coming years and as they said during TDX’22 Keynote, “Salesforce is now creating over the platform that we have been building during the last 22 years”. Just remember, for Salesforce, even if you do only low-code you are a developer .

 

Now that you know the main highlights, you may want to dive deeper and start with the Modern Way of Working. You can start here:

 

Want to read more from Rodrigo? Read his blog about his visit to Salesforce TrailblazerDX '22. Or view our open positions if you're interested to work with Appsolutely, just like Rodrigo.