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
Related
Background
According to the Visual Studio ALM Rangers, there are two major approaches to sharing resources (e.g. common libraries which are used in many separate products) in TFS 2012:
Workspace mapping, setting up workspaces so that they point to the appropriate version of each required library and product.
Shared folders, using branch/merge to get and update the shared resource
At a glance, shared folders seems like the way to go, but a client that I am working with has experienced a lot of problems with that approach in Starteam, and is reluctant to try it again in TFS. I am currently in the process of assisting the client migrating from Starteam to TFS.
I have listed pros and cons with each approach, but I am uncertain if I have missed something.
Workspace mapping:
Simple to setup and understand
Easy to test a library change in several products
Easy to get latest changes in a library, and to submit changes to a library
No tracability, or at least less tracability, e.g. if a change in a library was introduced in Product A, how to track that change in Product B
Changes in libraries may affect products in an uncontrolled manner
Build gets more complicated
Each user must set up his/her workspace individually (but there are workspace templates in TFS 2012 Power Tools)
Folder mapping:
Everything that is needed is configured in a given branch
Isolation between products and branches
Builds are simplified
More control of changes
Requires more disk space
Requires more administration in the form of branching/merging and setup of branches
One particular problem is how to test library changes in several products. As I understand that would require testing in product A, then reverse integrate to library and forward integrate to product B, then test that product and so on.
Conclusion, and final question
The client has successfully used something similar to workspace mapping in Starteam for 10 years, and plan to continue to use that approach in TFS. Although they have the problem to keep track of library changes that affects several products.
They are afraid that folder sharing will get messy and complicated.
My question is, have I missed something in my list above? Are there more reasons for why an organisation not should use workspace mapping, or for why they should use folder sharing.
I have several plugins and would like to create a nice update site to provide them. Some of them only contain core functionality (would not do anything, let's call them core-plugin) and others provide some functionality to the end user (they are dependent on the core plugins, let's call them useme-plugin).
now, I've created features for every useme-plugin. I included the corresponding plugin and set all dependencies (core-plugins).
these features, I've added to an update site.
When I try to install them now, I get complains that core-plugins are missing:
Cannot complete the install because one or more required items could not be found.
Software being installed: Useme-plugin 1.1.0.201108090928 (de.xxx.feature.feature.group 1.1.0.201108090928)
Missing requirement: Useme-plugin 1.1.0.201108090928 (de.xxx.feature.feature.group 1.1.0.201108090928) requires 'de.xxx.coreplugin 1.1.0' but it could not be found
Did I do anything wrong? I don't want to include the core-plugins into every useme-feature... Or do I have to do that? Can anybody help me to structure it correctly?
Features are ment to group related plug-ins that should be installed as a single unit on a target system. Thus you normally have a number of features for a non-trivial application:
the main feature with the base functionality of the application
a number of features for optional add-in functionality
a number of features with core functionality
a number of features with major collections of 3rd party plug-ins
Two or more features can include the same plug-in - the plug-in will still only exist in one instance on the target system. In special cases, several different versions of the same plug-in can even exist on the target system. In other cases where different features depends on different versions of the same plug-in, you have a conflict that must be resolved by the developer.
A feature can also include or depend other features, in which case, the depended-on features must be installed as well on the target system. Thus the main application feature depends on the needed core and 3rd party features and likewise for 3rd party features. The installation of the depended-on features usually happens automatically with p2. p2 is smart enough to only downloaded needed plug-ins when installing or updating...
At run-time, it does not matter how a specific plug-in ended up on the target system, which gives a number of options in your case.
When dividing plug-ins into features, you must primary consider the wanted applications on the target system and the wanted add-ins. It only gets really difficult when you have multiple applications or add-in that each use a sub-set of the core plug-ins or 3rd plug-ins.
You have not written whether you have a single application or a number of applications, so I assume you have a single application - it is rather easy to extend the idea to multiple applications that share a common set of plug-ins.
You can solve this problem in several different ways. The absolutely most simple solution is to make a single application feature and include the UI, core and 3rd party plug-ins in this - more or less as you suggest. This works fine if you just have a single product and don't expect to use the core plug-ins in other setups.
Often you divide your features to have core and UI features. Most often because the UI functionality is divided into different features to allow the end-user only to install the needed functionality.
So in you case, you can also have two features: the core feature and the application feature, which then depends on the core feature.
Or you can have
the core feature
a UI functionality feature - that depends on the core feature
an RCP feature (from Eclipse)
and main application feature that depends on all the other features
There are plenty of ways to do this...
I need a bit of clarity regarding whats possible with grails plugins before committing my self to a corner a month or two down the line,
We have two applications built in Grails what share the same model, however we are looking at creating a single application which will control the ACL and add the two Grails applications as plugins.
Now the two applications are very extensive and they have their own controllers, views and routing.
Is it still viable to integrate the two applications as grails plugins or is there another better way of doing it. In the past I have found that following a quick simple guide / tutorial on how to create a grails plugin for instance, might not really explain the other issues I might encounter as I take the two big applications which use plugins of their own and try to convert them to plugins...
Any heads up information would be appreciated.
Everyone's needs are different. I'll simply explain what we've done on a current project and then you can use that to help make your decision.
We have a "common" grails plugin. This plugin contains all of our domains, controllers, layouts, views, css, images, and js that are shared throughout our grails applications. The common plugin has the spring-security-core plugin installed since the security domains are, well, common to all the other applications. However, each application that uses are common plugin still specifies its own security. It uses the domains from common as well as the spring-security-core plugin installed in common, but each application can control its own access points and lock down the URLs that need locked down.
We have an admin application
We have a customer facing application which has both secured and un-secure content.
And we have a couple other internal only applications that use our common plugin.
We've been at this for 6 months and haven't noticed any drawbacks to this approach.
Our small development shop is looking to migrate our projects from VSS to TFS, and we're evaluating TFS vs. others (haven't pulled the trigger quite yet). The nature of our software shop is such that we have 100+ projects in VSS ranging from small one-man-show projects to massive enterprise-wide applications.
We are trying to determine how to structure our projects in the transition and have, for the most part, decided on putting everything into one project site/system with each project having a subfolder off the root.
With this type of setup, we are concerned that we will lose a lot of the functionality that TFS provides (bug tracking, scrum burndowns, reporting, document storage etc.) because all the projects will be in the same portal/project space and it will be difficult to separate out individual project tickets/items.
Does anyone have experience with this? What was your solution? Did you stick with TFS?
The answer to this question requires some planning on your part: how you intend to use TFS, and which of those capabilities has inherent limitations in the product. I would summarize my advice as:
You will need [at least] 1 team project per process template. That is, if two teams want to adopt / customize different processes, they will need to be separated.
Once condition #1 is satisfied, you probably don't need as many separate Team Projects as you think. 90% of TFS features & settings are hierarchical in nature, allowing you to scope them as broadly or narrowly as each of your projects requires.
For complete details, see:
http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Guidance%20for%20Structuring%20Team%20Projects
http://blogs.msdn.com/richardb/archive/2007/05/01/tfs-team-project-whitepaper.aspx
http://msdn2.microsoft.com/en-us/library/aa974183(vs.80).aspx
The approach I've taken was to have a TFS project for each logical grouping of assemblies -- So we've a framework project that contains assemblies common to all our applicaitons, we then have a separate project for our quotations system, another for the costing system and so forth. Whilst the workspace mappings get a bit "interesting", it does allow different design methodologies for different projects, and at different timescales -- so one team might be half way through a sprint (Most projects use Scrum for Team System), at the same time as another is just starting...
It is true that to garner all of the benefits of TFS, it is best to use separate projects, but those benefits should be weighed against the administrative overhead associated with managing many projects. Years ago, I used Visual Source Safe...After I left Microsoft, I switched to Subversion. After returning to Microsoft, I am using TFS and so far I am very happy with it.
The process guidance, the reports, the integrated bugtracking, and the tight IDE integration serve my needs perfectly. Plus, the TFS SDK allows for some interesting extensibiilty scenarios.
I've used several SCC providers and we've settled on TFS for all of the features it has that others don't. Bug correlation, CI and automated testing certainly topped the list of benefits.
As for whether you use multiple project or not, I'd say it depends on if the projects share any common code. We tend to use a TFS project for all "related" code assets, so if we have several different solutions that do similar things and share a lot of code, we use a single TFS project. If they have nothing in common, then they become separate projects.
I am not sure if this was fixed in 2008 but in 2005 when you built a project that was a subfolder of a root project, MSBuild will pull the entire source tree of the root project - even files that are not part of your subfolder.
Depending on how much source you are managing this can greatly increase your build times.
I realize this article is old, but TFS 2010 now supports a wonderful feature call Team Project Collections which is simply another level of indirection or grouping on top of Projects.
This makes it much easier to create Team Projects without clogging up your namespace and encourages better organization!
Great Link talking more about Collections
http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
I a not a sharepoint user but I hear its very similar concept to Sharepoint collections :)
My organization has begun slowly repurposing itself to a less product-oriented business model and more contract-oriented business model over the last year or two. During the past year, I was shifted into the new contracting business to help put out fires and fill orders. While the year as a whole was profitable (and therefore, by at least one measure, successful, we had a couple projects that really dinged our numbers for the year back around June.
I was talking with my manager before the Christmas holiday, and he mentioned that, while he doesn't like the term "post-mortem" (I have no idea what's wrong with the term, any business folks or managers out there know?), he did want to hold a meeting sometime mid-January where the entire contract group would review the year and try to figure out what went right, what went wrong, and what initiatives we can perform to try to improve profitability.
For various reasons (I'll go into more detail if it's requested), I believe that one thing our team, and indeed the organization as a whole, would benefit from is some form of organized code-sharing. The same things get done again and again by different people and they end up getting done (and broken) in different ways. I'd like to at least establish a repository where people can grab code that performs a certain task and include (or, realistically, copy/paste) that code in their own projects.
What should I propose as a workable common source repository for a team of at least 10-12 full-time devs, plus anywhere from 5-50 (very) part time developers who are temporarily loaned to the contract group for specialized work?
The answer required some cultural information for any chance at a reasonable answer, so I'll provide it here, along with some of my thoughts on the topic:
Developers will not be forced to use this repository. The barrier to
entry must be as low as possible to
encourage participation, or it will
be ignored. Sadly, this means
that anything which requires an
additional software client to be
installed and run will likely fail.
ClickOnce deployment's about as
close as we can get, and that's awfully iffy.
We are a risk-averse, Microsoft shop. I may be able to sell open-source solutions, but they'll be looked upon with suspicion. All devs have VSS, the corporate director has declared that VSTS is not viable going forward. If it isn't too difficult a setup and the license is liberal, I could still try to ninja a VSTS server into the lab.
Some of my fellow devs care about writing quality, reliable software, some don't. I'd like to protect any shared code written by those who care from those who don't. Common configuration management practices (like checking out code while it's being worked on) are completely ignored by at least a fifth of my colleagues on the contract team.
We're better at writing processes than following them. I will pretty much have to have some form of written process to be able to sell this to my manager. I believe it will have to be lightweight, flexible, and enforced by the tools to be remotely relevant because my manager is the only person who will ever read it.
Don't assume best practices. I would very much like to include things like mandatory code reviews to enforce use of static analysis tools (FxCop, StyleCop) on common code. This raises the bar, however, because no such practices are currently performed in a consistent manner.
I will be happy to provide any additional requested information. :)
EDIT: (Responsing to questions)
Perhaps contracting isn't the correct term. We absolutely own our own code assets. A significant part of the business model on paper (though not, yet, in practice) is that we own the code/projects we write and we can re-sell them to other customers. Our projects typically take the form of adding some special functionality to one of the company's many existing software products.
From the sounds of it you have a opportunity during the "post-mortem"to present some solutions. I would create a presentation outlining your ideas and present them at this meeting. Before that I would recommend that you set up some solutions and demonstrate it during your presentation. Some things to do -
Evangelize component based programming (A good read is Programming .NET Components - Jubal Lowy). Advocate the DRY (Don't Repeat Yourself) principle of coding.
Set up a central common location in you repository for all your re-usable code libraries. This should have the reference implementation of your re-usable code library.
Make it easy for people to use your code libraries by providing project templates for common scenarios with the code libraries already baked in. This way your colleagues will have a consistent template to work from. You can leverage the VS.NET project template capabilities to this - check out the following links VSX Project System (VS.Net 2008), Code Project article on creating Project Templates
Use a build automation tool like MSBuild (which is bundled in VS2005 and up) to copy over just the components needed for a particular project. Make this part of your build setup in the IDE (VS.NET 2005 and up have nifty ways to set up pre-compile and post-compile tasks using MSBuild)
I know there is resistance for open source solutions but I would still recommend setting up and using a continuous automation system like CruiseControl.NET so that you can leverage it to compile and test your projects on a regular basis from a central repository where the re-usable code library is maintained. This way any changes to the code library can be quickly checked to make sure it does not break anything, It also helps bring out version issues with the various projects.
If you can set this up on a machine and show it during your post-mortem as part of the steps that can be taken to improve, you should get better buy since you are showing something already working that can be scaled up easily.
Hope this helps and best of luck with your evangelism :-)
I came across this set of frameworks recently called the Chuck Norris Frameworks - They are available on NuGet at http://nuget.org/packages/chucknorris . You should definitely check them out, as they have some nice templates for your ASP.NET projects. Also definitely checkout Nuget.
organize by topic, require unit tests (feature-level) for check-in/acceptance into library; add a wiki to explain what/why and for searching
One question: You say this is a consulting group. What code assets do you have? I would think most of your teams' coding efforts would be owned by your clients as part of your work-for-hire contract. If you are going to do this you need to make absolutely certain that your contracts grant you rights to your employees' work.
Maven has solved code reuse in the Java community - you should go check it out.
I have a .NET developer that's devised something similar for our internal use for .NET assemblies. Because there's no comparable .NET Internet community, this tool will just access an internal repository in our corporate network. Otherwise will work rather much the way Maven does.
Maven could really be used to manage .NET assemblies directly (we use it with our Flex .swf and .swc code modules) is just .NET folk would have to get over using a Java tool and would probably have to write a Maven plugin to drive msbuild.
First of all for code organization check out Microsoft Framework Design Guidelines at http://msdn.microsoft.com/en-us/library/ms229042.aspx and then create a central Location source control for the new framework that your going to create. Set up some default namespaces, assemblies for cleaner seperation and make sure everyone gets a daily build.
Just an additional point, since we have "shared code" in my shop as well.
We found out this is very much a packaging issue:
Whatever code your are producing or tool you are using, what you should have is a common build tool able to package your sources into a "delivery component", with everything used to actually execute the code, but also the documentation (compressed), and the source (compressed).
The main interest into having a such a "delivery package unit" is to have as less files to deploy as possible, in order to ease the download of those units.
The build process can very well be managed by Maven or any other (ant/nant) tool you want.
When some audit team want to examine all our projects, we just deploy on their post the same packages we deploy on a production machine, except they will un-compressed the source files and do their work.
Since our source files also includes whatever files are needed to compile them (like for instance eclipse files), they even can re-compile those projects in their development environment).
That way:
Developers will not be forced to use this repository. The barrier to entry must be as low as possible to encourage participation, or it will be ignored: it is just a script to execute to get the "delivery module" with everything in it they need (a maven repository can be used for that too)
We are a risk-averse, Microsoft shop: you can use any repository you want
Some of my fellow devs care about writing quality, reliable software, some don't: this has nothing to do with the quality of code written in these packages modules
We're better at writing processes than following them: the only process involved in this is the packaging process, and it can be fairly automated
Don't assume best practices: you are not forced to apply any kind of static code analysis before packaging executable and source files.