Love the tool - some serious work has gone into it. If you are one of the maintainers reading this - let me start by saying thank you!
I am just reviewing the layering of steps for a cloud-based org to cloud-based org ADO migration (this is after working through a dry run migration).
Currently I have the below order.
I am unsure that I have understood the documentation correctly, does anyone know if step 9 should run directly after step 8 or if step 9 is reliant on step 10 to be ran first (changing the order to 8 -> 10 -> 9)
An additional note for others trying, in our setup we found that for Step 3, we had to also exclude the Shared Steps, Shared Parameters as well - as they are part of the Test scope. I will make an issue in the project on that item.
I appreciate any advice that can be offered - along with if you see any other mistakes in our approach. Thank you!
Step
Item
Notes
Dependents
1
Migrate the Org level inherited process
No errors
2
Create project with inherited process and then attach Custom.ReflectedWorkItemId to all work item types
Required by all below items
3
WorkItemMigrationConfig-configuration.json
Also migrates all areas and paths
Provides Area and Paths, below items heavily dependent on this
4
TfsTeamSettingsProcessorOptions
Teams,Areas,Paths are the 3 core components of Projects in the metamodel. Items below dependent on this includes Boards, Security group configuration
5
TfsSharedQueryProcessorOptions
Boards is dependent on this
6
TestVeriablesMigrationConfig
TestConfigurationsMigrationConfig is dependent on this
7
TestConfigurationsMigrationConfig
TestPlansAndSuitsMigrationConfig is dependent on this AND Delta-WorkItemMigrationConfig-configuration must be run in sequence afterwards this step. This has to be run before LinkMigrationConfig
8
TestPlansAndSuitsMigrationConfig
Must be run in order after TestConfigurationsMigrationConfig. The Test_scope_WorkItemMigrationConfig-configuration.json should be run after this
9
LinkMigrationConfig
This has not been run. The documentation suggests this should be run and run in order
10
Test_scope_WorkItemMigrationConfig-configuration.json
Current Assumption: Required for Work item migration for Test suite, Test Plan, Shared Steps, Shared Parameters
Ordering between this and LinkMigrationConfig unclear
11
Boards
12
Security Groups
Looks possible to achieve with code against the REST API for reproducibility
13
Wikis
Takes 2 minutes to complete the process using the ADO Web UI
14
Repos
Looks possible to write a REST API piece of code to automate for reproducibility
15
AzureDevOpsPipelineProcessorOptions
The processor includes scope of BuildPipelines, ReleasePipelines, TaskGroups, VariableGroups, ServiceConnections
In theory this could require Security Groups to be in place (although I don't think it is a dependency to achieve migration - only for execution)
Related
I have inherited a collection of Bamboo build plans and corresponding deployment projects. Here is a particular example of how I would like to leverage reuse. We a four deployment projects (say ProjA, ProjB, ProjC, ProjD) that can be run individually/independently. However, we also have a project where we deploy them together (call it ProjABCD). Currently, ProjABCD replicates the steps from the individual A, B, C, D projects and executes them consecutively (e.g., if each has 10 steps, ProjABCD has 40 steps).
Is there a way to have a super-project (ProjABCD) that simply simply "calls" the four individual ProjA, ProjB, ProjC, ProjD? Ideally, this would also be able to roll-back to baseline state if any project in the group fails to deploy properly.
You should be able to come up with a scheme using the triggers functionality. There should not be a need to have a 40 step combined deployment (that breaks a lot of the value the deployments provide). There are multiple ways to solve/simplify this problem. For example you may choose to have two different builds, and only one of them triggers the 4 deployments.
I have a build job which takes a parameter (say which branch to build) that, when it completes triggers a testing job (actually several jobs) which does some stuff like download a bunch of test data and checks that the new version is works with the test data.
My problem is that I can't seem to figure out a way to show the test results in a sensible way. If I just use one testing job then the test results for "stable" and "dodgy-future-branch" get mixed up which isn't what I want and if I create a separate testing job for each branch that the build job understands it quickly becomes unmanageable because of combinatorial explosion (say 6 branches and 6 different types of testing mean I need 36 testing jobs and then when I want to make a change, say to save more builds, then I need to update all 36 by hand)
I've been looking at Job Generator Plugin and ez-templates in the hope that I might be able to create and manage just the templates for the testing jobs and have the actual jobs be created / updated on the fly. I can't shake the feeling that this is so hard because my basic model is wrong. Is it just that the separation of the building and testing jobs like this is not recommended or is there some other method to allow the filtering of test results for a job based on build parameters that I haven't found yet?
I would define a set of simple use cases:
Check in on development branch triggers build
Successful build triggers UpdateBuildPage
Successful build of development triggers IntegrationTest
Successful IntegrationTest triggers LoadTest
Successful IntegrationTest triggers UpdateTestPage
Successful LoadTest triggers UpdateTestPage
etc.
So especially I wouldn't look into all jenkins job results for overviews, but create a web page or something like that.
I wouldn't expect the full matrix of build/tests, and the combinations that are used will become clear from the use cases.
My questions is as follows:
Is there a way to make a master project plan incorporating multiple projects (not necessarily sub projects) in Microsoft office. As our resources get pushed around due to parts and items not arriving and shipping dates being moved forward amongst other things etc, sometimes the resource plan has to be changed regularly. I want to be able to pull all current projects into a master project plan so that I can identify where project resources are overlapping. Not necessarily by task but more by employee.
To try and explain a bit better:
Project 1:
Project Manager: John
Project Engineer: Jack. Task - Drawing
John assigns Jack to work on a task in Project 1.
Project 2:
Project Manager: Mark
Project Engineer: Jack. Task - Documentation
Jack wasn't supposed to be working on Project 2 for a further 2 weeks but the deadline has been moved forward and Mark has also assigned Jack to work on a task on his project.
I'd like to create a master project where I can pull in Project 1 and Project 2 and find a way for it to identify the resource overlap, regardless of the fact that Jack has been assigned to 2 different tasks, but more because he as an employee has been assigned to two projects at once.
Is this possible?
On a larger scale realistically I'll need this to incorporate about 6 Projects and about 20 staff members across, so I can find all the overlaps.
I am aware that there is a way to split a person between 2 tasks by assigning a percentage that they will work on both, i.e 90% on task 1 and 10% on task 2 but obviously this won't be project exclusive and my aim is to identify the overlaps rather than create them on purpose for resource sharing.
You are basically looking for software to support your "resource leveling" process.
The ]project-open[ open-source PPM software is capable of importing MS-Project schedules. After the import, you can get Resource Management reports from the system that allow you to perform manual resource leveling.
Another interesting open-source tool is TaskJuggler. TJ actually does multi-project scheduling or automatic resource leveling. However, TJ does not include a MS-Project integration at the moment AFAIK.
Affiliation note: I'm a member of the ]project-open[ team.
Depending on how you want to approach this, you can have a single master project and make all of your other project files sub projects in that master file. You can work in this master file and it will save your updates to the other files. It is sort of like having Project server on your desktop. You can create veiws for each project, or simply roll them up and they show as a single summary task.
You can do this by using a shared resource file but the best way now would be to just get a Project Online subscription and do your projects there.
We've been using TFS since around 2009 when we installed TFS2008. We upgraded to TFS2010 at some point and we've been using it for source control, work item management, builds etc.
Our TFSVersionControl.mdf file is 287,120,000 KB (273GB). We ran some queries and found that our tbl_BuildInformationField table is massive. It has 1,358,430,452 rows which takes up 150,988,624 KB (143GB). We have multiple active products over multiple active builds which more than one solution per build and the solutions aren't free of warning messages.
My questions:
Is it possible to stop MSBuild from spamming the
tbl_BuildInformationField table so much? I.e. only write errors and
general build information and not all the warnings for every
project?
Is there a way to purge or clean up old data from this
table?
Is 273GB for 4 years of TFS use an average size?
Is 143GB for tbl_BuildInformationField a "normal" size?
The table holds the values and output of build process. Take note that build retention policy doesnt actualy delete the build object like everything else in TFS the object is marked deleted and only public visibility and drop location is cleared.
I would suggest if you have retainened same build definitions for very long time (when build definition is deleted the related objects get removed as well) you should query for build info including deleted ones using TFS api, the same api will also alow you to remove them for good. Deleting build definitions probably will not work and will fail with timeout error.
You can consult the following:
http://blogs.msdn.com/b/adamroot/archive/2009/06/12/working-with-deleted-build-data-in-team-foundation-server-2010-beta-1.aspx
My question may sound a little bit stupid.
My team has to test a Web application that it is used by 3 different User Roles. So, we start by writing our Test Cases based on the User Stories. My problem is that I don't want to create 3 different Test Cases for each User Role. I think that this needs a lot of time when writing the Test Cases and later testing them because:
Total Test Cases Number = User Stories x Test Cases Per User Story x User Roles Number.
Moreover, I don't want to create new Test Cases if some time in the future a new User Role will be created because they will be just duplicates with some little differences.
Is there a better way to manage this situation?
Thanks in advance.
Single Responsibility Principle?
Code and test the user access separately to the user story, unless you really do get a completely different story based on your role, in which case, its a distinct spec and warrants its own test.
Not sure on the coding front (depends on what the situation is and how the code is implemented), but I can answer from a testing perspective (2 yrs so far, over half of it in a traditional waterfall system migrating to Agile).
The web application I test is similar in that we have three user types (global) and three user roles (tied to "projects" which are buckets of sites, sites in term as buckets of imagery, look-up EyeQ if curious). So, 9 possible combos, 8 of which can make a site. Current regression procedure doc has over 100 test cases, 20 or so are edit/create/delete site. total overall: 500+ test cases majority are manually run (ongoing efforts to automate them, but takes time as we've gone thru a UI reboot).
Anyway, I've had to rewrite some of our manual procedures as a result of the sweeping UI changes and am trying avoid the mistakes authors before me made, such as the one you describe (excessive repetition aka reuse same test three times with slight variations).
Rather than stick to their strategy of writing cases, I use looping (same term applies in coding)- that is, test cases that use one role-type combo per pass. Instead of having the same test case written 3+ times and each executed separately for each role/type, use the procedure once but add a few steps at the end.
example test case:
user can create a site (8/9 of the type-role combos can do this in my app)
what they did before I came in:
test case 1- sys admin not tied to project can make site (10 steps);
test case 2- sys admin with project role can make site (same 10 steps);
test case 3- account admin not tied to proj can make site (same 10 steps as 1st case);
test case 4- account admin with proj role can make site (ditto);
test case 5... and so on
what I do:
test case 1: Do 10 steps as user with combo 1,
step 11- log out as that combo, log in as user with combo 2 and repeat 1-10,
step 12- log out as user from step 11 back in as user with combo 3 and repeat 1-10,
...
The difference:
3+ test cases or 30+ steps executed (in this case, about 100)
vs
1 test case: under 20 steps
Take this with a grain of salt though, it depends on your type of problem.
If it really is repetitive (as with the example) try to loop as much as possible.
The advantage is, when you get an auto-test framework up, a simple for-loop within the test case with an array object or struct for input.
The disadvantage is, it wouldn't be as modular (takes an extra 30 seconds to find problem cause if something breaks, but that's my opinion).
No need to confuse. You need to just make Matrix for access rights Vs. User Roles.
For e.g :- Raw : User Modules(rights of users)
Column : User Role
Just mark in excel sheet that which user have what type of permission or access.
You can also download some tools which has ability to generate this type of permutations and combination.
You can download from here.
https://testcasegenerator.codeplex.com/
Download Test Case Generator
It is greate tool for measure permutaiion and combination in accurate way.
We have tested these role-based test cases for a huge enterprise application with close to 38 roles and 100s of fields editable or not editable across more than 15-20 web pages using mind maps.
since there were a lot of workflow statuses linked with each role, the thorough testing was needed.
Add a generic test case covering functionality and permissions and mention in test notes to execute the test case for each role as per mind map designed. Attach the mind map to test case.
We converted the test cases into mind map:
Sample MindMap
Mind maps helps in consolidating large chunk of data into a pictorial form that made easy for understanding the test cases and speeds up the execution.
Simply create a table of user roles listed vertically and a list of functions mentioned in the step horizontally. Then mark yes or no in each cell for that role. Repeat for each step. You can put your step description to verify the user’s authorization to perform the action based on the table. If you have a test data column you can put the table there.