In a ClearCase and RAD environment instead of creating multiple workspaces and views for multiple users, can we create a set of workspaces and views per functionality and share this across multiple developers by updating the configurations like config_spec.
Btw, the views that i would like to share are Snapshot views created on a network drive.
Regarding the views, the short answer is yes: you don't have to be the owner of the views to checkout them. But that will certainly work for read-access (and need to be tested for write/checkin cases).
But regarding RAD workspaces, it is best that each developer maintains his/her own one, configured to access the right common view.
Related
I'm thinking to move to Azure DevOps. But I'm at the stage where it's hard to decide which option will be useful.
My Requirements:
Single dashboard for the current sprint to have transparency to
everyone in the team. No context switching.
Single backlog for all projects.
User stories & bug will be easily identified by project.
Reports by projects, teams, etc.
Service hooks - Microsoft teams, etc.
Source control - GIT.
Artifacts.
Test plans under one board.
I'm thinking of going with single project(multiple repositories)
But before going down this road I just want to know what are the pros and cons of both options.
In general, we recommend that you use a single project to support your organization or enterprise. A single project minimizes the maintenance of administrative tasks and supports the most optimized / full-flexibility cross-link object experience.
Even if you have many teams working on hundreds of different applications and software projects, you can most easily manage them within a single project. A project serves to isolate data stored within it. You can't easily move data from one project to another. When you move data from one project to another, you typically lose the history associated with that data.
So according to your situation, it is recommended to use a single project with multiple repos and multiple teams. For details you can refer to this official document.
Reasons to add another project
You may want to add another project in following instances:
To prohibit or manage access to the information contained within a
project to select groups
To support custom work tracking processes for specific business units
within your organization
To support entirely separate business units that have their own
administrative policies and administrators
To support testing customization activities or adding extensions
before rolling out changes to the working project
To support an Open Source Software (OSS) project
(Posting the question here as this is the 'community' that Microsoft redirects to with a 'Need advice? Ask community' button. Hope it won't get closed as 'primarily opinion based' or 'too broad')
Hello,
I want to start using AzureDevops in my department for organizing code & work. We're a small team who creates a large number of applications & plugins.
Some of these applications have a very short lifecycle, i.e. we deliver them, and they work for years without changes. Other apps are larger and are updated/fixed across several months or years.
These applications are completely separate from each other in all aspects.
As far as I understand Azure DevOps structure, my department should become an 'Organization' (we can/need to be separate from the rest of the corporation).
I am a bit puzzled about the 'Project' part. Documentation says
In general, we recommend that you use a single project to support your organization or enterprise.
So, let's say we do have one project called Our Apps - where do we then put all the individual application-projects?
As far as I understand, each product (application) that we deliver should have it's own repository (or a set of applications, if they are logically connected).
This is in order to allow a developer to simply clone the repo on their machine and contribute to that product only - without downloading other projects etc.
I need to be able to:
easily navigate/see all the tens/(hundreds?) of applications that we create,
view their separate kanban boards (for those project that do have it, not all of them will)
to see their repositories (Git or TFS), commits etc
see & manage their pipelines
At the moment it seems to me that the only place where I can see a 'list' of what products do we have is the drop down below:
And the only way to see what is going on in the big-enough-to-get-own-board products is by creating a new separate 'SomeApp Team' in the Project (even though same people are in it), so that I can have a board for the SomeApp - and view the boards from here:
Is that the intended way to organize the structure?
Any alternative approaches?
Is there any way to have a 'cross-reposistory' or 'cross-team' overview?
What about creating documentation for each 'product'?
The "one project to rule them all" was coined by Martin Hinshelwood and his blog post from way-back-when explains the reasons and limitations.
With the introduction of Tagging and filtering on the backlog there is an alternative approach within the one-project setup.
Create team for the real teams you have in your organisation.
Create an area path for each major project/product in the org.
Assign the area paths of the projects to the teams who are working on them. This can change over time.
Optionally tag work items with the major project/product for additional filtering.
This way each team sees a complete view of all the work they can pull from. And they can quickly filter the work by tags to remove items from view when discussing specific projects/products.
Also, when teams change their focus from one product/project to another, you can simply change the assigned areas for that team to update their view.
The Plan View extension provides an additional cross-team view across over all the work. And the Dependency Tracker extension can visualize dependencies over time.
You can also use the Epic/Feature/PBI|UserStory tree structure to create additional grouping in your work items. You can customize the process template to introduce a Product level, though for the planning features to work, that would also mean that you'd also have to create full traceability from Product down to PBI|UserStory.
The main recommendation is to try a few of these approaches in a light-weight manner to see how they work and find your own ideal setup.
Another option for cross project visualization is to enable the Analytics Extension and connect it to PowerBI.
As you'll soon figure out, naming guidelines for your Tags, Repositories, Pipelines is going to be very important. Being able to quickly filter to the right level requires this.
Company has projects each of which have their own accounts, opportunities and contacts.
Each project is self contained. So if I'm working in project (A), I don't need to see any elements from project (B).
I'm not sure how to achieve this. Separate sugarCRM install per project?
If they are completely self-contained, and the number of projects will not change frequently then two separate instanced could indeed make sense, especially if the projects will need different CRM customizations and have different users. If there are users that work with both projects, you could maybe add some solution that shares the login session across both CRM instances (e.g. single sign-on) for convenience reasons. I don't know if there are good solutions for that available.
If you however decide to use a single CRM for both projects, I only see those options:
Use Team Security to control which record can be seen/accessed by which teams->users (a.k.a. row level security). This is a built-in feature in commercial versions of Sugar. For SugarCRM CE and SuiteCRM there appear to be similar 3rd party plugins available for purchase.
Create different account/contacts/opportunity modules for the projects in ModuleBuilder. I strongly advice against this, especially if you use forecasts. There are tweaks, features and functionality that are programmed to only work with the default modules. Those will not work properly with such custom modules. So additional to the effort of creating those modules (and maybe keeping their customizations in sync, if they are supposed to be the same across both projects) you will also have to fix/work-around/code things that work in the default modules but not in the custom ones. If the projects are wildly different and of sufficient size to justify the extra effort, this could be worth it. Otherwise: don't
I've been through all the permissions you can grant to groups at the collection level (https://[account].visualstudio.com/_admin/_security), but don't see any permission that looks like it'd control the ability to read/admin all the projects in the collection. I don't even see any inheritance that's giving the "Project Collection Administrators" group admin rights over the projects, which is making me afraid that it's just 'magic' that I can't customize.
Any thoughts on what I'm missing here?
Expected this to be a snap once I figured out how to let non-admins create projects (yeah, it's really that easy). I've got to be missing something here.
No, read/admin permission can’t be granted globally for all projects. You should set permissions for different projects separately.
For a project security setting (https://account.visualstudio.com/projectname/_admin/_security), you can add users who’s permission is read in reader group.
As with most systems if you find something hard then you are probably using it wrong.
https://nkdagility.com/one-team-project/
The majority of your users should be spending the majority of their time in a single Team Project. The Team Project boundary isna hard one to cross and flipping between team projects is a pain. Fpr most organisation and most product teams one Team Project is all you need.
I need way more info to be sure, but your question implies to me that you have a whole bunch of team projects that the sake group of users need access to. This makes it a pain to manage security and you want to create server level groups to manage this. Now while the Product Team are working hard to address things like this it will take time to make the underlying changes that would enable it.
In the mean time you should look to merge all of your Team Projects into one (or logical groups based on people/product/assets that allow users to access as few team projects as posible.
As an example the Office, Windows, Xbox, and VSTS teams at Microsoft's all have one team project each. Even though they have multiple projects, teams, and products under each.
As a rule of thumb: If you have assets that interact then they should all be in one team project. I defign assets as people, code, or work items.
I'm looking for a best practice scenario on managing multiple "sites" in mercurial. Since I'm likely to have multiple sites in a web root, all of which are different - but somewhat similar (as they are 'customizations' of a root app)
Should I
A) make a single repository of the wwwroot folder (catching all changes across all sites)
B) make EACH sits folder a different repository
this issue is that each site needs a distinct physical directory, due to vhost pointing for development, and a current need to have "some" physical file difference cross site.
What's the best practice here? I'm leaning towards separate repositories for each directory. which will make tracking any branching and merging for that ONE site cleaner....
It depends on how your software is structured, and how independent the different sites are. The best situation is when you can use your core code like a library, which lives in its own directory, and there is no need in the different sites to change even a single file of core. Then you have the free choice if you want to develop the core along with the different sites in a single repo, or to seperate core from sites. When core and the different sites are dependent on each other, you very probably have to deal with all of them in a sigle repo.
Since in my experience development work better when the different parts are independend of each other I strongly recommend to bring the core stuff into something which can be included into the sites by a directory inclusion.
The next point is how are the different sites developed. If they share lots of code, they can be developed as different branches. But there are two disadvantages of this scheme:
the different sites are normally not visible to the developer, since there is typically only one checked out
The developer has to take great care where to create changes, so that only the wanted changes are going into other branches, not something which is special to a single branch only
You might consider to move common parts of different sites into core if they share lots of common code.
Another situation is if they all have nothing in common, since then things are much better. Then you need to decide if you want them to reside in different repos, or as different directories in a single repos. When these different sites are somehow related to each other (say that they are all of the same company), then it might be better to put them into a common repo, as different subdirectories. When they are unrelated to each other (every site belongs to a different customer, and changes on these sites are not created in synch to each other), than one repo per site is better.
When you have the one repo per site approach, it might also be good if you first create a template site, which includes the core component and basic configuration, and derive your site-repos as clones from this template. Then when you change something in the core which also affects the sites, you do these changes in the template, and merge these changes afterwards into the sites repos (you only need to take care to NOT do this change in one of the site-repos, since when you merge from sites to template you might get stuff from the specific site into the template, which you don't want to be in the template).
So I suggest
develop core as a single independent product
choose the correct development model for your sites
all in one repo, with branches, when there is much code-exchange is goin on between different sites
but better refactor the sites to not share code, since the branches approach has drawbacks
all in one repo, no branches but different folders, if there is no code exchange between different sites
one repo for each site if they are completely independent.
I think, you have to try Mercurial Queues with one repo. I.e
you store "base" site in repository
all site-specific changes separated into the set of MQ-patches (one? patch per site)
you can create "push-only" repos in sites, add they to [paths] section of "working" repo and push changes or use export-copy technique
and after applying the site-patch to codebase you'll get ready to use code for each and every site