Monthly Archives: October 2018

Automated Deployment and Dynamics

 

Automated deployment has always been a bit of a problem in the Dynamics world to say the least, and, of course, we hit exactly the same walls while working on the most recent project. Here is what we came up with – you might (or might not) find it useful..

In the core of this approach is the idea of “packages”. Apparently, it’s been around for a while in different forms, but have a look at the diagram below:

image

In the package preparation step, we are aiming to define the package as a set of solutions, data, and corresponding actions.

Our Build step is all about converting that definition into something that can be later deployed into the target Dynamics environment.

And in the Deploy step we are actually doing the deployment.

Imagine that you’ve done it for one package, then for another, etc. And, then, imagine that you have at least 3 environments:

Dev – UAT – Prod

Ideally, you should have more, but it’s another story.

So, you keep preparing the packages in Dev and deploying them packages to UAT. You’ve done it for the first one, for the second one, etc.

At some point, you want to bring production up to date.

You already have packages, so all you need to do is repeat the same deployment steps – deploy the first package to production, deploy the second one, and so on until your production environment is up to date. As you are deploying each of the solutions, you also need to repeat the same actions (run data migration workflows, delete attributes and entities, etc)

There are different tools in the SDK that seem to be doing part of what we need (Configuration Migration tool, solution packager, package deployment..), but there is always something missing there. For example, Configuration Migration tool does not seem to be able to export team roles, yet data export cannot be fully automated – the data package has to be prepared manually.

So I came up with another tool – it’s on GitHub:

https://github.com/ashlega/ItAintBoring.EZChange

It’s a windows application that you can compile in Visual Studio and run.. Though don’t expect a commercial-grade product at this point. Some things are simply missing – at the very least, I still need to add progress bar indicatorsSmile

However, here is what you can do with that tool so far.

1. Create a package and save it to a file. Save all your packages to the same folder – this will allow the tool to run those packages to various environments as required. Every package can use variables (this is how you can run the same package to different environments without having to update the connection strings in the package itself. Variables are stored in a separate file)

image

2. Add solutions to the package(can be solutions from the source environment or  from a file) and define different actions for each solution

image

3. Build the package – for now, at least, orderedpackages.txt file and variables.xml file have to be created manually

image

4. Run the package from the UI or from the command line

If running from the UI, use Build->Run option to run the current package.

If running from the command line, use the following command:

ItAintBoring.EZChange.exe <Path to the packages folder> <Environment Name>

5. You can define the order of your packages in the orderedpackages.txt file:

image

6. You can define environment-specific variable values in the variables.xml file:

image

7. As for the available actions, here is what’s in there so far:

– Export data (it’s a build –time action which will use FetchXML to export data from the source)

– Import data (it’s a run-time action which will import data to the target environment)

– Workflow action (run-time action to run a workflow on a set of records identified using FetchXML)

– Metadata action (run-time action to delete attributes/entities/workflows/etc)

– Deploy solution action (run-time action to actually deploy a solution)

8. The tool is extendable

Even though the code is on GitHub, you don’t always have to modify the base code. For example, if you realize that you need more “actions”, you can create a new .NET dll, implement a class that’s inherited from BaseAction in that dll, put that dll into the “Extensions” subfolder, and the tool will pick it up next time you run it. That’s how the “Core” pack covering Dynamics is implemented anyway.

Breaking SCRUM

 

Here is a Scrum-related problem which I’m sure has been discussed before and will be discussed again.. so it’s just me thinking out loud.

We have developers, we have testers, and we have business analysts on the team. Our product owner is not a single person but a group of people where various stakeholders come and go. And, yet, we are still trying to do scrum.

To start with, why are we trying to do scrum? I think that’s because scrum is offering something.. it’s almost like a promise.. a promise of bringing some order to the chaotic process we used to follow before. With its product backlog, sprints, product increment, and well defined timeboxes, it seems to be just what we need.

And, then, well-defined scrum theory collides with the reality – we don’t have a single product owner

image

We were not given one.

I think that’s the single most important problem any Scrum team could have, and I am wondering if there are, really, Scrum teams that don’t have itSmile Really, I can only salute the organizations that understand the importance of this concept.

Instead of the product owner, we have to have a few business analysts constantly chasing different SME-s for the requirements. This is not unusual, sometimes those business analysts are called proxy product owners.

But, of course, the idea of having a single product owner is all about having a single point of contact and a single product authority on the Scrum team. When we have so many people responsible for the user stories, the whole thing is turning into a bit of a zoo quickly.

There are questions all around – for example, as a member of the dev team, am I supposed to ask the BA or am I supposed to ask the SME-s when I have questions about the user story? Anyway the BA-s will likely have to confirm the answers with the SME-s, so why not to ask directly? But, then, the BA-s might find themselves a bit out of the loop, and there is a reason they need to be aware of all those discussions – developers can’t just start chasing all the SME-s, there has to be at least some order.

Actually, are we supposed to treat business analysts as members of the dev team?

My personal opinion – we probably should not. Sure they would be members of our scrum team, but not the dev team, right?

Well.. On the flip side, what is right for the product owners is not necessarily correct when it comes to the BA-s. Just like, from the dev team standpoint, BA-s are representing the product owner, from the SME-s standpoint BA-s are representing the dev team. And they can’t do it unless they get involved into the dev team discussions etc.

Then how far do we get it? Should the business analysts participate in the estimation exercises? It’s a bit of a stretch if they do, since they really don’t have much to say as far as development/testing is concerned, but, on the other hand, if they go back to the client to discuss those estimates.. they have to be prepared. It’s hard to be a proxy.

See, what was, once, a well-defined framework, is quickly becoming a set of assumptions, questions, and workarounds which we have to come up with to accommodate just a single change in the framework.

Which is, we don’t have a dedicated product owner.

So now I’m wondering.. would it be possible to sort of turn a BA into a product owner? To make the Scrum whole again? It would definitely be a challenge – business analysts will have to become much more familiar with the business in this scenario, but, as a result of this transformation, a lot of communications and decision making on the project might become much more simple.

It is not for the Scrum team to “raise” a product owner, though, it’s for the organization to do. Did anyone try doing this?

“Share/Unshare” Relationship Behavior – something to keep in mind when working with the hierarchies of records

You might be creating a number of new entities, all related to each other through a hierarchy of relationships, and, then, you might have to set up security so that, if a user were given permissions to the top-most entity in that hierarchy, that user would also get access to the other entities.

Imagine, for example, that you had a Parent and a Child entities like this:

image

And the security permissions for regular users are set up like this:

image

image

So the users can do whatever they want with the records they own, but they can’t even see somebody else’s records. The record above was created using a system admin account, and here is how a user having only “user-owned” read permissions can’t see any of those:

image

So let’s say the system admin decides to share that parent record with the user:

image

The record shows up:

image

But there is still a problem – the user can’t see any of the child records:

image

Remember there were supposed to be two kids there?

And of course they would not show up since we only shared the parent record, so all the child records would have to be shared with the user separately.

Is there an easier way to do the same?

This is where “Share/Unshare” properties of the relationship behavior might be very useful. By default, you will get “Referential” behavior there which will look like this:

image

What if we change that to “Configurable Cascading” and update “Share/Unshare” to use “cascade all” instead so it looks like this:

image

Save, publish all.. Re-share the Parent record(may have to actually un-share, and, then, share).. ask the user to reload their “Parent” screen, and, lo and behold, those lost kids have just been found:

image

Most importantly, those Child records are not shared directly with the user:

image

It’s all taken care of through the relationship.

And why is that important? Because there are all sort of scenarios where this can come into play. For example, consider the access teams. You can create an access team template for the parent entity only, and, if the relationships are set up as described above, just by adding a user to the parent record’s access team, you will grant that user access to the whole hierarchy of records without having to do it individually on each of those records.

Entity Relationships in the Business Process Flows

There was an interesting story today which came out of the It Aint a Problem experiment.

Basically, a question came in with an example of a business process flow which looked more or less like the one below:

image

There is a branch in that BPF – basically, if there is an existing account, then the BPF is supposed to skip account creation, and, instead, there is a stage where a contact will be created/updated. So the question here was why, when navigating to the final stage, we can’t choose the account and we have to create it instead? Even thought that contact has “Company Name” field populated with the correct account already:

image

Actually, I did not get it, at first, what the problem was and it took me a little while to even understand what we were trying to do. Then I was confused – indeed, why is it not showing up? Especially since, when using the other branch (where the account is already there), we can go smoothly from one stage to the other:

Pick the contactimage

Then go back to the account – no selections are required

image

Turned out it’s the story of relationships – it’s all about who is the parent, and who is the child.

Those two branches are working off the different relationships which may not be obvious when looking at the BPF definition.

The “normal” branch is using the following relationships/lookups:

  • From leads to accounts: Origination Lead
  • From Accounts to Contacts: Company Name
  • From Contact to Accounts: None (to use the account that’s already linked to the process)

So, in this scenario, Account is the “parent” and Contact is the “Child”.

In the alternative branch, however, the contact is linked to the process first, and, then, there is a “switch” to the account. That switch is supposed to happen over a certain relationship/lookup, but, in that case, since the Contact is already linked to the process, it’s the Account that is the “Child”. So the relationships are different this time:

  • From leads to contacts: Origination Lead
  • From Contact to Accounts: Primary Contact

Here is how it looks like in the BPF definition:

image

So, once there are a couple of account that have this particular contact set as a primary contact, it all starts to work as expected:

image

And what is the takeaway? When we have a business process flow with different branches(actually, this may probably happen with just one branch, too), the same entity can be added to different stages. So we might intuitively expect to see the same selections whenever we are switching from a different stage to one of the stages for that entity. However, the business process flow might be using different relationships in those cases so the selections may end up being quite different.

It Aint a Problem – a simple offer for anyone having questions about Dynamics

Please note: This offer is on hold as of October 29, 2018. Did not get any but one question in October, so will be focusing on other things for now.

imageWhat kind of questions do you have about Dynamics? Are you about to start a new trial to evaluate what’s doable? Are you facing a technical/functional issue where you are not sure how to do something? Is there a tricky security question that’s bothering you? Is there a plugin that’s not working as expected?

Whatever the problem is, I have a simple offer for you: let me have a look at it and see what can be done.

And if you wanted to ask what it’s going to cost you, here is the kicker.. it’s free. As in absolutely free.

But no worries, there is certainly a catch – I have a few conditions:

  1. Whatever the question/problem is, it should be related to the online environments, and it should have an element of a problem in it. In other words, it should be something that cannot be easily answered just by looking at the documentation or by asking Google
  2. By allowing me to look into it together with you, you are also giving me permission to blog about it. Which may mean I’ll be taking some screenshots, but I’ll certainly remove all sensitive data from those screenshots before posting them anywhere (and you can choose whether I should be mentioning any names or not)
  3. I cannot guarantee my unlimited availability, so it’s all going to be based on the “best effort” approach. I can choose to say upfront that I’m not interested, I don’t have time, I have 5 hours, that we need to have a look at it first, etc
  4. Last but not least.. I’ll certainly be doing this in good faith, but things happen. You won’t hold me responsible for the possible loss of data and/or for any other problem that may arise as a result(or as a perceived result) of us looking at it together

 

Is it a fair offer? Get in touch and let me know what you think