On Azure DevOps Server 2019, I wish to customize my backlogs and boards to add new levels and WITs, as described here.
Doing so requires the new Inherited process model, however, and my collection was created some years prior to the model's introduction (I've gone through three upgrades in the time since). The model must be selected at collection creation; it's not possible to switch between the two after the fact.
It appears I must create a new collection, and then migrate all of my data (Work Items, Repos, Pipelines, etc.). Naturally, I need to preserve all internal timestamps.
Is this possible, and if so, how is it accomplished?
It's not easy, there are options but they all involve a compromise on the integrity or fidelity of the things migrated.
If you only have a single project you could use the Free version of Ops Hub, or pay them some money for the full version. However I believe that this will change the timestamps if checkins to TFVC to the migration date / time (although I believe it adds the original date / time to the checkin comment.
Or you could migrate the code to git using git-tfs. You might be able to preserve the full commit history but that depends on certain things not being done in TFVC (renaming branched for example)
Pipelines I'm not sure but I know that some colleagues have been experimenting on doing this via the API. Depends on if they are the new ones or the old XAML based builds.
Work items can be migrated using Martin Hinshelwoods tools
I think that Microsoft are looking at this though. I had a call with them back in may based on this tweet and it looks like they are going to be adding the ability to migrate to the new template type to the on prem version at some point in the future. Not sure when though
Related
I did a check if this has been asked before but the closest I found were questions around a single application with different branches for clients.
What is the best strategy for handling multiple applications in version control? Say I have 5 completely separate applications that can require changes at any point. Do I put them all under the same main trunk (origin/master if you will) then branch off as required or should they all get their own trunk?
Let me know if it's not described well and I can add more information.
You should see the Branch strategically:
When should the team add a branch?
You should create branches in the following situations:
When you must release code on a different schedule/cycle than the
existing branches.
When your code requires a different branch policy. If you create a
new branch that has the new policy, you can add strategic value to
your project.
When functionality is released to a customer and your team plans to
make changes that do not affect the planned release cycle.
You should not create a branching for each user story because it
creates a high integration cost. Although makes branching easy, the
overhead of managing branches can become significant if you have many
branches.
In you scenario, It's based on how do you want to manage the applications, different schedule/cycle ... then you need to track in another branch as David mentioned above. And if the size of applications are very large, you can even version control them separately in new team project.
This article for your reference : Branching and Merging: Ten Pretty-Good Practices
We have the full Atlassian product range and I am looking at how to make best use of it
We are using Stash to manage our Git 1000+ repositories all of which contain tags pointing to their versions.
I need to be able to define how our software versions depend on each other
For example:
System_x.y.z in production consists of
group_of_components_a_x.y.x consists of
component_a_x.y.z
component_b_x.y.z
...
System_x.y.z is release candidate_a consists of
....
System_x.y.z is in regression test
...
System_x.y.z is in performance test
...
System_x.y.z development is being tracked by Issue#
...
etc etc
I have been using ClearQuest to achieve this but would like to move to a pure Atlassian solution if it exists
I would also like to define a name for group_of_components so that I can attach owners to it as well as to components so we can use them elsewhere in the workflow.
can notify them when versions change.
In Issues so I can see when different teams are working in the same areas
I would also like to be able to use the System_x.y.z, group_of_components_x.y.z and component_a_x.y.z
In Defects so I can see where the error was found (System_x.y.z, group_of_components_x.y.z)
In Defects so I can see where the error was fixed (component_a_x.y.z)
Is any of this possible?
Is any of this possible?
The short answer is yes. It's all possible.
Jira has the following hierarchy:
Project
../ Epic
../../ Task
../../../ Sub-task
If you need to track version numbers as part of a product roadmap you need to use Projects for that feature. There are probably other hacky ways to use labels or components to do something like this but you will spend endless hours extending these hacks throughout Jira. Not a fun exercise IMO.
I need to be able to define how our software versions depend on each other
Dependencies can easily be added at the Epic/Task/Sub-task levels but I'm not aware of an easy way to do this at the version level. I'm only really aware of the Agile Cloud solutions. If you install this locally I'm fairly sure you could find a way to do this if it is truly needed.
I would also like to define a name for group_of_components so that I can attach owners to it as well as to components so we can use them elsewhere in the workflow.
It's very easy to name all issue types and projects. Projects have an owner. All issue types can be assigned to any user (with access rights). Additionally you can add users to the "watch-list" of every issue.
can notify them when versions change.
The watch-list will notify all watchers by email. Additionally you can set up workflows to reassign or marshal each record through a custom workflow.
In Issues so I can see when different teams are working in the same areas
You can add users to teams in any combination (users can be on multiple teams) but I'm not sure I fully understand what "areas" means. You can search, filter and report on all issues by team(s) if that's what you mean.
I would also like to be able to use the System_x.y.z, group_of_components_x.y.z and component_a_x.y.z
In Defects so I can see where the error was found (System_x.y.z, group_of_components_x.y.z)
In Defects so I can see where the error was fixed (component_a_x.y.z)
Each bug you define:
can be organized into an Epic
can be associated to any number of tasks (Blocks task 1 or is blocked by task 2, etc.)
has one or many "affects versions" to track where the bug occurred
has one or many "fix versions" to track when the bug was fixed
I'm looking for a general process for handling model changes in team environments, specifically where a branching model like Git Flow is used. I want to use lightweight migration, but I'm concerned how this works if multiple developers are versioning within their branches.
I prefer to version only when changes need to be made to the model, rather than pre-emptively.
When working with a team, I'd recommend whomever needs to make model changes to check with the other members of the team that it is ok to version the model, primarily checking if the model had already been versioned. If it hadn't been versioned yet, then I'd have the dev issue a pull request to develop for just the model version bump. Once that is merged, then anyone who needs to make changes to the model for the next release can pull the newly versioned model from develop and make their changes on that new version. Merging changes from different developers on different branches to the same model has not in my experience been a difficult process.
With all of this, I'm thinking only of lightweight migration, which in most cases is likely all you will need. For manual migrations, which are likely going to be rare, I'd recommend taking a more ad hoc approach that satisfies the particular needs of the project.
Overall, I think the best approach is to version the model once per release.
Generally,
In case of early development (pre-release)
No need for versioning (and therefore migration) as this would just slow down development. Devs and QA will just need to reinstall the app for every model change.
Once the app is ready for release
At the beginning of every release, i.e. when the release branch is created, the lead developer should create a new data model version on the develop branch. This will allow multiple devs to make changes on feature branches without the need to coordinate (i.e. "who's going to version the model? and how are we going to get that into our branches?").
Data model changes on the release branch are discouraged
This will likely break the migration path from the previous release.
My company uses TFS 2008 with the MSF for Agile process template. We are in the process of planning an upgrade for TFS 2010. We use Scenarios as a container for functional requirements with linked development tasks, bugs, etc.
In order to save the state of a Scenario as 'Resolved' or 'Closed', I would like to enforce that any development task or bug that is linked to the scenario is also closed. With TFS 2008, these are links, in TFS 2010 we plan to use child work items.
I have been reviewing the work item type definition schema and MSDN documentation, but nothing is jumping out at me as a solution to this problem.
Can it be done? Thanks in advance for any help!
What you want cannot be done directly. The saving of a work item is what is called a Notification (rather than a Decision). That means that you can only do TFS API stuff in an event after it is done. You cannot block it.
However, there are ways to get the "effect" of what you are looking for. If you modified your template so that your parent work item (I think you called it Scenario) had the State control (not the field) as read only that would make it so that only clients that don't use the normal Visual Studio controls can change that value. (This could be worked around by your users, but it would take some effort to break the rules).
But there is one more step. You need to get the parent work item to "Resolved" somehow. For this I recommend a open source tool that I wrote called TFS Aggregator. (Or if you plan to "roll your own" you could use the code there as a starting point.)
You can find TFS Aggregatoron codeplex here: http://tfsaggregator.codeplex.com/
It is a great tool for rolling up changes and totals to parent work items. You could put in a rule that when your child items are all "done" to move the Parent to "Resolved".
EDIT: I realize now from your question that you have more than one type of Work Item as a child of the parent Item. TFS Aggregator does not support that right now (but it may in the future). It was written to aggregate tasks to Bugs or PBIs. Still, it would probably be easier to modify the code of that project than to start from scratch.
I don't think this is possible "out of the box". I would recommend you write a query to find cases where the "rule" is violated and handle it that way.
If you MUST automate this - You could use the TFS Eventing Service which can invoke a Web Service.
Set it up for when a Task or Bug is closed - query the database for the Scenario and if all the Task/Bugs are closed - use the TFS API to advance the Status to Resolved or Closed. You could limit the allowed user to make advancement to the account the Service runs under.
I am currently a single BI developer over a corporate datawarehouse and cube. I use SQL Server 2008, SSAS, and SSIS as my basic toolkit. I use Visual Studio +BIDS and TFS for my IDE and source control. I am about to take on multiple projects with an offshore vendor and I am worried about managing change. My major concern is manging merges and changes between me and the offshore team. Merging and managing changes to SQL & XML for just one person is bad enough but with multiple developers it seems like a nightmare. Any thoughts on how best to structure development knowing that sometimes there is no way to avoid multiple individuals making changes to the same file?
SSIS, SSAS and SSRS files are not merge-friendly. They are stored in an xml file that is changed drastically - even with minor changes (such as changing a property) - so it becomes really impossible to merge.
So stop thinking about parallel development on one file. You need to think how you can achieve that people are not need to do parallel development on one file. So start with disabling the multiple checkout of a file. You might even want to consider to enable the option to get the latest version on a checkout.
Then start thinking how you can achieve that people can work independent. This is more in the way you structure the work and files:
Give people their own area they can work on. One SSIS package is only developed by person X at any given moment in time.
Make smaller files so the change that two people need to work in the same file is small.
I have given feedback to the product team of the imcompatability of BIDS to merge. It is a known issue, but will be hard to tackle. They don't know when it will be possible to really do parallel development on these files. Until then keep away from parallel development.
As Ewald Hofman mentioned, SSAS and SSIS is not merge-friendly.
In one environment I worked solved the problem as follows:
do only use SSIS when you have to (fuzz algorithm or something similar). Replace SSIS packages as often as you can with SQL code (see Linked Server for datasync. and MEARGE Command for dimension/fact-table-creating for instance).
build your data warehouse structure as follows:
build 2 databases, one for the "raw source data" from the source systems and one (the "stage" database) for the dimension and fact views and tables
use procedures that can deploy the whole "stage" database
put the structure for the "stage" database into your Repository
build a C# application that build your dimensions and cubes via the AMO API (I know, that's a tough job at the beginning but it is it worth - think on what you gain - Look at the Pros below )
add the stage database and the C# application to your Repository (TFS/Git etc.)
Pros of that structure:
you have a merge-able structure you can put in your Repository
you are using the AMO API witch has
you can automate the generation of new partitions
you can use procedures to automate and clone measure groups to different cubes (what I think is sometimes a big benefit!)
you could outsource your translation and import it easily (the cube designer is probably not the best translator)
Cons:
the vendor would probably not adapt that structure
you have to pay more (because of either higher skill requirements or for teaching him your individual structure)
you probably need knowledge over a new language C# - if you don't already have
Conclusion:
there are possibilities to get a merge-friendly environment
you will get lost of nice click-and-run tools f.e. BIDS - but will get into process of high automation functionality
outsourcing will be maybe unprofitable because of high individualization
http://code.google.com/p/support/wiki/DVCSAnalysis
maybe a better tag is DVCS?
https://stackoverflow.com/questions/tagged/dvcs
As long as both teams are using bids and TFS this should not be a problem.
assuming that your tsql code is checked in to source control in a single file per object, merging TSQL code is straight forward since it is text based. I have found the VSTS Database projects help with this.
Merging the XML based source files of SSIS and the MSAS can be cumbersome as you indicate below. to alleviate some of the pain, I find that keeping each package limited to a single dataflow or logical unit of work helps reduce developer contention on packages. I then call these packages from one or more master packages. I also try to externalize all of my tsql source queries using sprocs, view or udfs so that the need to edit the package is further reduced. using configuration files and variables also helps to a smaller extent.
MSSAS cubes are a little bit tougher. My best suggestion is to look into a 3rd party xml differencing tool. I have been able to successfully merge small changes use the standard text based tools but it can be a daunting task.