I have inherited an Azure Data Factory solution in my new job. It has been worked on by at least 6 different BI developers. I'm currently busy with cleaning up my Azure Data Factory, fixing version control, and making sure that all my three environments are the same.
Some objects seem obsolete to me. To check if it is obsolete, I go over to the portal, and check the objects Properties if it is related to another object.
If not, it is a confirmation for me that the object is not (yet) used and I can safely remove it from the solution.
Is there an easier way than checking each object?
I figured it out and wanted to share it here. It is possible to check the "orphaned" objects in an ADF instance, however not directly from the UI. Paul Andrew has an excellent blogpost about his script that is able to check your ADF code against his best practices. The relevant checks for me are:
Pipeline(s) without any triggers attached. Directly or indirectly.
Dataset(s) not used by any other resource.
Trigger(s) not used by any other resource.
Linked Service(s) not used by any other resource.
The last check can also be done via UI, see #AbhishekKhandave-MT answer.
Step 1: Export ARM template to a local folder, and unzip it
Step 2: Download Paul Andrews PowerShell script from here
Step 3: Open the script and replace the $ARMTemplateFilePath variable with the path to your ADF ARM template. If you want to check out the details, change the $VerboseOutput variable to $true
Step 4: Run the script and check the results.
Here are my results, so 58 datasets are not used by any other resource.
Unfortunately, there is no other way to find whether object is used(yet) or not.
But you can check number of datasets linked with a single linked service as shown in below screenshot.
Manage > Linked Services
Click on number in Related column.
Related
I'm looking to migrate a project from one org to another in Azure DevOps. We've ended up with two or three orgs, and this project that I'm looking to move has all sorts of weird and wonderful work items created and custom fields added. What I'm looking to do is move the project and then see if I can persuade the powers that be that certain things can be dropped but I have an immediate need to move as-is so that reporting and other work isn't impacted.
I have tried to get this to work with the migration tools (and tried to follow the videos) but have hit a dead-end. I think there are two issues potentially. One being the ReflectedWorkItemId. It says that it's not found in User Stories but I'm not sure how to resolve this? Do I go into user stories and add a field called 'ReflectedWorkItemId' and populate it with the work item number and/or add the same field in the destination org process?
It also mentions in the info that it can't find one of the Work Item Types - Processes. There are a few other custom work item types that have been created too but I assume it's given up on the first one. Do I have to create all of the work item types and the custom fields for each work item type in the destination org? Or am I getting the wrong end of the stick with this?
To provide sync as well as migration it is important that the tools knows which items have already been migrated. This is the purpose of the ReflectedWorkItemId field.
The field is not required in either case, however... if you don't have
the field then the system cant be re-run as it will re-copy all
completed work items. If you add the field to the target then it will
only copy those items it cant find. If you add the field to the source
(yes it needs to be the same refname), and set UpdateSoureReflectedId
to true then you can also filter the source, using a query and limit
what you load.
The former prevents duplicates, and the latter allows you to filter
the data load...
This is mentioned in this document. Here is a similar issue you can refer to.
TF201077 that usually happens when the target Project does not have a work item of that name. You can refer to this issue on github for help.
We are using Azure Devops Server. When a bug is created, I would like to create a child task automatically. The task does not need to have any particular properties, it just need to be created with default values and have a default name like "Placeholder" or something like that.
I have already encountered some different ways of doing it, but neither of them seems to be well suited for me:
The extension 1-click-child-links could be used to create a child task by clicking a button in the context menu after creating the bug. This will of course work, but it would be even better if it could be done in the background ensuring the task to be created even if the user forgets to click the button.
As I understand it, using the Microsoft Flow software tasks can be created in the background when creating a bug which would be exactly what I'm looking for, but it would be nice to find a simpler way of doing it without installing a complete software tool.
I've learned that it is possible to hook into different events by using service hooks (https://learn.microsoft.com/en-us/azure/devops/service-hooks/events?view=azure-devops). There are a couple of standard integrations, but neither of them can be used to solve my case. So using this method, I guess I need to develop a custom service creating the task?
Is there a simpler solution to achieve my gool or do I need to stick with one of the solutions above?
As a workaround , we can set Azure Logic App, select When a work item is created"as trigger, and then select Create a work item as action.
Make sure to set the Link URL to the “When a work item is created” URL and set the Link Type to Hierarchy-reverse to create the Task as a child of the Bug item. Please refer to the settings below:
Save the Logic Apps Designer, and then when the bug item is created, the child task named Placeholder will be automatically created.
I have a list of pull requests, each linked to the specific work items. I want to run a pipeline only for some of the work items. Therefore I would like to somehow automatically cherry-pick only commits/pull requests related to work items I want to build. Either using tags on work items or something similar. In the build, I need only the files which were changed, so I was thinking of using git diff.
Is that possible using the Azure Pipelines?
If I understand your request correctly, you need to run the build pipeline only for those pull requests which meet certain requirements, for example, are linked to the work items tagged with specific words. Although I'm sure there's no out-of-the-box solution to this, I think it is possible to achieve with the Conditions concept and the REST API.
I would follow these steps:
The very first build step in the build job should be a script to find out if this particular pull request being built is related to the target work items. It can be a PowerShell build step, which should:
Get the pull request ID - it is available as a predefined system variable called System.PullRequest.PullRequestId
Make a REST API call to get work item IDs related to this pull request. It will return a collection of {id, url} pairs, where id is an ID of the work item in question
For each found work item ID, make a REST API call to get the details of the work item, in particular, you're interested in the System.Tags property of the response
Again, for each work item, parse the System.Tags property value to find out if it contains necessary tags
If at least one related work item contains the tags you're interested in, set the flag variable called i.e. ShouldRunTheRestOfThePipeline to true
Conditionalize the further steps of the job with the custom condition. You can read more about the syntax of the expression here. In particular, the Q&A section describes how to use the variable set in the previous build step in a subsequent step's condition
Now, regarding your notes about taking only changed files. In fact, the pull request nature is to keep the changed files compared to the target branch it is created against. So, you don't need to do any extra actions to git diff - the pull request already contains all you need.
Finally, I would suggest you reconsider the requirements of this setup, 'cause it sounds a bit unnatural to me. There are other options for how not to trigger a pipeline. For example, it can be decided based on the branch/tag name, both include and exclude options are available. Or, you can specify file paths to include or exclude, for instance, never trigger a pipeline if only docs/* were changed. The wildcard syntax is supported, which makes this tool even more flexible.
Hope this can help you build a suitable solution to your specific scenario.
I have a Personal Access Token about to expire in DevOps/VSTS, but I can't see it in DevOps to do a ctrl-f and find it in my source code.
I have an Angular 2+ frontend with a .net core api backend.
Which file should I be looking at? Does it need to go in the backend? Or Frontend? Or both?
config.json? project.json? Which property is it (if it is a config file like that)?
Or is it somewhere else I need to update this? Not in source code, but something with the build agent? How would I update that?!
Which file should I be looking at? Does it need to go in the backend?
Since we could not clearly know how is your script look like, I assume you may not remember clearly about this because of huge script files. For this, Azure Devops has a feature Search can search what you want across all your code.
For any repos which with a api called, we suggest you search the code files first with Search feature. And also, you may pass the token value with task variable. So, you also need to check your pipeline variable.
I do all development in a single application. when a new version is ready I create a template and give it a version number. this way I can store a history of all previous versions.
the development templates are used to push the new design to many applications via replace design.
Creating manual version number or template names is fine but I am looking for a more automatic way of finding out which build the different applications are inherited from
When I visit the different applications I would like to be able to see which build number each application are inherited from. is this possible?
A simple build time stamp could do, but is there a built in build number that can be used and that can be displayed on the xpage.
e.g Build 2012092712345
Update:
Thank you for all your answers, many good suggestions but it looks like all require manual work.
The best solution would be if there is a way to read (from ssjs) a timestamp from any file within the nsf that is always updated during a build. is this possible?
In classic notes, there was a method to add a shared field with a special name to the application. Cannot remember the details, but have it somewhere on the disk.
Then you can see the build number in the design tab of the application properties. And you can of course display the value in your applikation as well.
But you have to fill the item manually on each build. Or use teamstudio Buildmanager. This tool adds the value automatically.
And I also guess that you can write some code that changes the value whenever you create a new build.
Another option would be to use a versioning system like CVS/SVN. This is possible since 8.5.3.
Source control
I think I know what you are meaning. Your a pushing out design and want to check thru code what version each database has. I usually do this with a Build form. In this form I have computed fields with all the data I want to retrieve. Then I open the database with an agent create a document
and set the form field to "BuildForm" and do a computewithform.
Now I can see all information about this database.
I once wrote a rudimentary build system for "classic" Notes, and had the last part of the build pipeline create a form named _BUILDID_, and put the build id in the $Comment field.
The main reason to create a form instead of a shared field was that I could dynamically fetch the form using NotesDatabase.Forms, and open up the desired field.
I sure hope there are simpler solutions nowadays... :-)