Tag: Salesforce Page 12 of 24

In the previous post, we outlined a simple process, which did not solely focus on development but instead considered the path a feature takes from definition to production deployment. A, well, release process.

And although for us Salesforce developers it seems tons of unnecessary overhead, there is a reason, why multiple parties are involved: it’s a system of checks and balances to make sure that features are stable and according to end-user expectations.

Imagine you shop online for a TV and you get delivered a simple 23” monitor. It’s kind of similar, but not what you wanted. And although you can see a movie on it, it will not fit the use case you had in mind when ordering a kick-ass UHD supersmart ludicrously large television.

A process introduces the necessary structure for defining, developing, testing and delivering a feature so you can watch the world cup with your friends (no jokes about Italy please…).

We also introduced Copado as our release management platform in the last post, and we did not ditch it. It allows to unify and drive the collaboration between teams, and there are specific items, where I think Copado help teams to do their job.

But I want to take a step back further, because in order to know how a tool can make a process more efficient, we need to understand how each team in a project impacts overall delivery time. So instead of talking about technology, I want to focus on people in this post, describe the roles typically involved in a Salesforce implementation, their tasks and what each team member can do to improve the flow.

Excuse me, but: what exactly are you doing?

Let’s recap the process focusing on the tasks per team member:

Define a feature:

Working in an agile way, a feature is usually defined by client business stakeholders, ideally by the product owner. As there are a lot of features to be defined and also tested, the project setup includes one or more business analysts to support the product owner in story definition, documentation and follow up. Toughened in uncountable meetings and armed with knowledge about the business process they tend to become advocates for the business side and bounce ideas with developers to get a feature done in a way business will like it. We could spend a whole post on that topic, but for now: time for action.

Develop a feature:

Well, do magic. But stay in time and in scope. Oh, and please, make it as scalable and maintainable as possible. You know, the usual.

Peer or Lead Dev review and rework:

Regardless if you just do a face to face explanation or if you use a more structured approach, such as a pull request: having your development reviewed has too many benefits to skip it. It prevents you from introducing a bad design crippling the project in the long run for short term success. Insights are shared within the team so there are no surprises. And you become a better developer through feedback.

If you work with Git (which is surprisingly easy with Copado), a pull request can prevent you from introducing bad items in your feature branch, which at the end will result in easier deployments.

Deploy to QA:

Well, this can be easy or an endless pain. If you work with Git, follow the golden rule, and you should avoid most of the issues:
– Review your commits and never include other people changes as part of your branch. (See why the pull request comes in handy?)
– Less references → less potential deployment errors or conflicts.

Test a feature:

There are elements in this world, which are natural opponents bound in eternal struggle. Water and fire for instance, or cats and dogs. And of course:

(copyright: https://www.monkeyuser.com/2018/the-struggle/)

Yet, without testers, our features would be less robust and might not be according to business requirements. Or even worse, we could break existing functionality. And believe me, you rather prefer a testers feedback, than explaining to your project manager and business sponsor why you broke the internet. On larger implementations, you are more likely to have a QA team focussing on writing and reviewing tests for current developments and automating regression testing.

Finally, the approval of a feature, at least in agile, can only be performed by product owners or delegated business users.

They ordered a TV, so only they are entitled to approve they received one.

Teamwork in software development is a real thing

Great, now we know the main roles involved in a project. But how does that help us to improve our releases? I mean, those business analysts, they don’t do development or any Git stuff; just talking, meetings and powerpoints. How can they possibly impact delivery speed?

A lot.

Analysts: Define and conquer

User stories are an easy way to capture requirements. Right? Well, yes and no.

Yes.
Because the basic format is easy. For instance: as a user, I want to see how much is an account worth, so that I always know on what to focus during sales and service.

No.
Because it misses tons of details. How do you calculate an account’s worth? Where should you see it? In which moment? Do we need information from other systems? If so, do we need it in real time? This simple story could result in fetching the latest orders from the ERP system on account page load.

Here is where the business analyst would spend time with the client, guide them towards a reasonable solution and future iterations and document it as part of the acceptance criteria.

Regardless of your project framework and methodology, good acceptance criteria fulfill at least three criteria:

• Provide process context.
• Provide enough information for the developers to know what to do, so they can outline a design and estimate the effort.
• Be precise enough to be testable. Who needs to log in? Where should you navigate? What action do you need to perform to get a result?

Ultimately, the time invested in documenting decent acceptance criteria will result in multiple benefits for other teams. For instance, less guesswork for developers during estimations and test scripts can be written in parallel with development.

As we use Copado as our release management solution, the User Story created by analysts will be used by developers to scope and deploy the changes. How neat is that? Definition, estimation and deployment all aligned.

Developers: A short cut for you but a long run for the team

After a feature is defined (estimated, prioritized and included in the sprint backlog) it is time to develop it. Done.
But is there anything a developer can do to increase process efficiency?

Just as the business analyst can impact overall speed by investing time in preparation, a developer can impact delivery to production investing time in working according to best practices and reviewing his or her work.

• Documentation, for example, is something most devs dislike, however it is crucial for others to understand the overall design and making informed decisions when moving the feature towards higher environments.
• Writing org-independent apex tests, which don’t rely on existing data. Just remember: every time you write @isTest(SeeAllData=true) a kitten dies with puppies crying and unicorns get sad.
• Do not hardcode references to a specific org. Do that and the unicorn will fade away.
• Check your feature branch, if you work with Version Control (Git). Always make sure that, whatever is committed in your feature branch includes your feature only. A peer or pull request review process can help to catch those wrongly committed items (e.g. reference to a field you don’t expect in a layout or a report type).
• Make reviewing easy. How? Well, what about pasting the URL for feature definition and documentation in the pull request description? Takes less than a minute, but saves minutes in searching for the reviewer.
• Perform a validation deployment towards the target org including running the test classes.
• Write down pre or post deployment tasks in an understandable way, because it might be that less tech-savvy team members need to perform them.

So that’s it? Well, not entirely.

With the right solutions in place, such as Copado, you can even go further, and there is a good reason to do so: there’s more than one deployment.

In our setup, there are two deployments required to release a feature. One to QA and another to Prod.

But what if your pipeline has further orgs? Staging, for example, a hotfix org and multiple dev sandboxes? In such a scenario, each manual step needs to be executed multiple times for different orgs.

Luckily Copado has some fancy logic under the hood, which can increase the level of automation considerably, so that you don’t even need to worry about hard coded references (yes, indeed).

In the next post we will take a closer look on how this can be achieved, but just as a teaser, the magic words are: Deployment Tasks and Environment Variables. And of course: “Please”.

Test team: Heavy lifting – easy testing

In an ideal agile world business testers would just check the functionality against the acceptance criteria and say yes or no, but the reality paints a different picture. Client stakeholders are caught between user story definition workshops, maybe their ongoing non-project work, internal stakeholder management and testing. Therefore a dedicated QA team can be of great value to drive testing effort, where better preparation results immediately in a shorter test time.

As soon as a feature is in a QA environment the clock starts ticking, so the core objective of the QA team is to make sure, that everything is ready for client business stakeholders to test and approve the functionality (or reject it (-_-) ). Here are a few things the QA team can do to prevent a story being stuck in testing:

• Ensure you have a test script indicating the steps to follow to achieve a certain result. If acceptance criteria are well documented they will come in handy to work on them in parallel to story development.
• Get the test script steps approved from a peer, who ideally dry-runs it on the dev org if the feature is available.
• Make sure testers have access to the org with the appropriate permissions to execute the test. Just in case, because who would miss something that obvious, right?
• Dry run tests in QA org, to avoid any surprise. Not required, but highly recommended.
• Identify a test owner who will perform the test, with the help of business analysts and/or product owners.
• Chase and support business for and during testing. Make sure they are notified and co-ride tests to support their efforts.
• Chase and support developers if issues are found and a fix is required.

If you think: “That sounds like a lot of documentation, tracking, monitoring, and coordination.”, you are completely right and tooling can help here which in our case it is an easy thing. We defined the user story in Copado with all the required agile information, then developers used it to commit and deployed their changes to QA. The test team can use the same User Story record to define their scripts and track execution. Nice.

Release Managers: Connect the dots to align

Analysts document, developers work according to best practices, testers prepare. So, what can release managers do to move features faster to prod? Apart from the obvious tasks this role implies (e.g. helping teams to fix errors and resolve conflicts) release managers are owners of the overall release process, the technology enabling it and as a result they need to run continuous improvement efforts. Sounds like lean management? Absolutely. Reducing errors, increasing automation and avoid waste (including time) are key lean principles – and still valid, although we produce software instead of cars (or TVs).

Ok, let’s say I’m a release manager. What do I need to do?

• Increase tooling knowledge. Regardless of which tool you use, you can only apply what you know, and being aware of what a tool can do is your foundation.
• Monitor and analyze the process. What are the steps done by the team? How long they usually take? Is there anything which you might have missed?
• Analyze challenges. Some deployments are easy, while others may take ages. List them down and investigate the root cause.

Once you have a good overview you can start applying your knowledge to tackle the issues:

• Identify and implement automation. Even smaller improvements add up. For instance, we could fire a message to the assigned tester as soon as a story is in QA and the script is approved. With Copado this can be done easily with a process builder.
• Document solutions. Usually deploying Salesforce metadata is easy. Select, deploy, hope, done. Yet some metadata types, such as profiles, standard picklist values or processes have their own tweaks to them. A good documentation of best practices and how to handle specific situations will enable teams to avoid pitfalls.
• Listen to the team. Yes, people complain – often with a valid reason. So although nobody likes to get complaints, resolving them will lead to improvements.

Because in Copado your overall flow is aligned to User Stories and you have the power of the force.com platform on your fingertips you can tinker around with your Copado installation to provide you the information required. With process builder, you can set up time stamps on the User Story object to analyze the time spent per step and identify bottlenecks. You can even make dashboards and share them with your team.

And if you don’t have a dedicated place where you store process documentation, just create a new object to document solutions, and another one to hand in suggestions (which you later can take as input for User Stories).

Technology does not implement technology. People implement technology.

With all the innovation, features and what not being released each week, we sometimes forget that at the end of the day you work with people. You might like one more than another, however everyone who participates in an implementation is bound to a common goal. There is real value in working together, communicating, helping each other at the cost of being nice. Even to testers.

And once you got your team mojo going, the next logical question is: How to make it faster?

Well, this is the moment when tooling is back on the main stage. Copado has some nice features on how to automate steps in your process and in the next post we will take a detailed look at how to set it up so you spend less time with clicking around and more time with the team.

And watching the FIFA world cup on a kick ass UHD super smart ludicrously large television.

A devs life could be so easy…

Developing a feature in Salesforce is easy, right?

• Log into your org
• Use (mostly) some point &bmp; click methods to enhance logic, user interface or the data model
• Done

Sounds like it is developed.

But it is not delivered.

Although the feature is technically done, it is not available for end users in the production environment. Also, nobody tested if it fits the business requirements or if it breaks existing functionality.
In addition, maybe someone should take a look at your feature, if it is aligned with the overall solution design.
Oh, and in order to minimize business impact, deployments to production may be restricted to specific time windows per week.

Sounds like we as a team should follow a process to release features in a controlled way.

This is how we roll

There are a variety of processes for release management out there as each team is individual, but usually they structure a series of quality gates in a flow.
Taking the example from above, the high-level process would probably look like this:

So far so good, but now we have a challenge.

Production deployments can only be done at certain moments so what happens, if one feature is tested and ready to go and another one is still being reworked, and both share components such as an Account Layout?
Oh, and we want to have a backup of our metadata (not only classes) to be able to roll back, in case we have an issue after deployment?

It would be great, if we could work in a way that tracks changes over time and allows to release specific versions of our metadata.

Git for the save.

As described above, developing on the Force.com platform can be very straight forward. But apart from Flows and Process Builder, old versions are lost, once you save your changes, e.g. Classes, Formulas, Validation Rules or Layouts.
To avoid that, you can store local copies of your metadata by retrieving it (e.g. through Workbench or ANT Migration Tool). You can also deploy the retrieved items. So we could use that to account for our prod deployment, but that sounds like a lot of effort to manage those local files and versions.

Here is where a Version Control Solution (VCS) comes in handy. And by the frequency VCS is being mentioned, it has become an important pillar for working with Salesforce. There are several solutions out there (SVN, Mercurial), but as of now Git can be considered industry standard.

So instead of storing retrieved items on our hard drive using different names and folders for tracking versions, we can simply store them in our Git repository, which will track changes. This will allow us to go back to an earlier moment for rolling back changes or deploy a specific version from the past.

That escalated quickly. Can it be easy again?

Let’s take a step back.

What started out as an easy way to build valuable business features, suddenly sounds somewhat complex. Being able to roll back, having quality gates in place, all those are valid points, but now as a developer apart from creating functionality and work peer and QA feedback, you also need to do something with ANT or Workbench then storing it in Git and then deploy it?
Is there an easy way to do this?

Yes, Copado.

To get started, you need to download it from the AppExchange or the Copa.do website. Also, as the goal is to work with version control, get a free Git repo from GitHub or Atlassian/Bitbucket.
Next you need to connect Copado to your Salesforce environments (Dev, QA and Prod in this case) and set it up with the Git repository. There is a quick-start guide you can follow with links to additional documentation. While you set up Copado, you notice that it is natively build on the force.com platform. So your knowledge about Salesforce is all you need to modify it (This will be important later, so keep it in mind).

Once the setup is done, the process described out above using Git version control as source of truth would be the following with Copado:

Define feature in Copado

Assuming most Salesforce implementations are done in some form of Agile, it can be done in Copado directly, including all required information, such as Sprints, Epics, Acceptance Criteria or Story Points (click here for more details).

Scrum Masters and Analysts can use the Work Manager and Kanban Board to manage stories, roadmaps and sprints.

Develop feature in your environment

Let’s get to the part we like: get creative on how to solve the business issue in Salesforce. This one is easy indeed.

Perform a peer review in your environment

This is done between developers, however, we would like to document the results with a flag to mark the story as “Review Passed”.

Here is when the catchphrase “native force.com” turns into a benefit.
Just create a Checkbox on the Copado User Story object called “Peer Review Passed”, make it available for the required User Profiles and put it on the User story layout. Done*.

*: Wait, you work in Production directly? You can use Copado to deploy this modification.

Deploy to QA

So far so good, let’s go ahead and deploy. Scared?

Just click on “Commit Changes” on the Copado User Story, select your items (use column search and sorting to make your life easy), provide a message and finish your commit.

Back on the User Story page, check “Promote & Deploy”* and the following will be done by Copado**:

• Create a feature branch
• Retrieve the items you selected
• Commit the items you selected on the feature branch
• Create an intermediate Promotion Branch merge your feature branch on it (more info on the branching strategy can be found here)
• Perform the deployment using Git as source

You can review your selections on the story, and click on the “View in Git” links to quickly navigate to your repository.

** bonus points if you click on “Validate” to make sure you can deploy







Test user story

Once the story is deployed to the next environment, it will be visible on the User Story page and we can change the status to “Ready for testing” and notify the Test Team through chatter.

If you are thinking “Wait, this just a record update in Salesforce and it could be automated easily”, you are completely right! Wait for the upcoming blog posts.

As soon as the test team approves the story, they can set the status to “Complete”.



Deploy to Production

Testing is done, and we can move to Prod. But wasn’t there something about other stories modifying the same component and them not being ready?
Well, this is the beauty of version control. Copado will pick the feature branch contents for deployment and those did not change. Your story is independent and you can work in a true Agile way.

Check “Promote & Deploy” again.

Done.

That’s it. That’s all?

Well, not exactly. The tool offers tons of functionality which can make your life easy, such as the way profiles are trimmed and deployed with Git, an engine to remove (or replace) unwanted tags from xml files, modules for recording and automating testing, and the easiest way to handle Salesforce DX you have ever seen. You can even launch internal Copado logic through Process Builder!

Check out on their demos or browse a little the documentation to get an overview of what is possible.

We, however, will leave technical feature descriptions aside and focus at improving our process, as there are elements which will need to be tackled to get your team closer to smooth releases.

• You’ll never work alone, so how to improve releases by working as a team?
• Deploying with a simple click is maybe too easy. Can we implement quality gates?
• Those are too many clicks. Can we automate this?

Look out for the next post, where we will take a closer look at the involved team members and how Business Analysts can play a key role reducing the time required to release a feature.