Background
We are a B2B company with no in-house developers. We're current outsourcing all our development work to a small software company. They've built their own custom CMS, which we are using.
At the moment, we're in a redesign phase where a new website is being build by this same software company, again tailored to work with their custom build CMS.
At the same time, we are planning to have a webshop, which is going to be built by a different company, a big E-Commerce software company.
What we need
In the end it should be one website, on the same domain. Where content and commerce should go hand in hand. Everything should be seamlessly integrated with each other, for example the search function (they both offer their own search engine), content and products.
Wouldn't it make more sense to let one company build everything instead of two different companies? What are plus or downsides to work with one or two companies in this case? Where could it go wrong?
I'm a bit scared when we work with two partners, that the total cost of ownership is going to rise to the moon. That it will bring a lot of inefficiencies with it and we're hindered when it comes to further scaling.
P.S. I'm not a final decision maker within this company, but I'm looking for input in order to change the current plan (which is working with two partners).
An interesting scenario that you are in here.
Wouldn't it make more sense to let one company build everything instead of two different companies?
Based on your description there is nothing in this that is particularly out of the ordinary. A website for your company with an online shop. There is no good reason why you need two contractors. What I mean here, is that there is no reason why one company cannot provide the expertise to deliver both parts. Adding a second company / contractor will add more complexity to the situation and therefore breaks the generally good rule of keep it simple. (More on this later).
What are plus or downsides to work with one or two companies in this case?
The positive of working with two companies is that you can get experts in the different areas. For example if company A is an expert in one part of the solution and company B is an expert in another you get the combined expertise. However, in this case there doesn't seem to be a need for this.
Where could it go wrong?
This is very much the downside of having two companies working on this. The two companies will need to work together to provide the solution. This is likely to require some management from you (or your company) which you correctly identify the cost of ownership can significantly increase. You run the risk of both of your contractors pointing the finger at each other when things go wrong.
I would strongly recommend at least considering using a single company for the whole project delivering a combined website and online shop.
I recently read an article, "www. is not deprecated", which strongly advices against redirection from www to no-www. I would like to know the main cons of such a redirection and the main cons of redirecting from no-www to www. How would it impact site scalability, search engines visibility, problems with cookies, etc.
I'm going to suggest something controversial. It doesn't matter. Use either domain.
There are legitimate issues with serving content from a single domain with HTTP 1.1. You have to do domain sharding in order to parallelize content. However browsers only open up 4 connections at the same time, so even that scaling is limited. This is called sharding.
However the issues of sharding are gone with HTTP/2. With HTTP/2 you can parallize assets natively over a single connection. https://http2.github.io/faq/
When you need to scale beyond a single server you'll be faced with other issues, but throwing more hardware at the problem will be the easiest solution. When your site becomes so large you'll want to use a Content Delivery Network at which point, scaling becomes a non-issue for the front end.
There are issues with cross domain cookies. If you do scale to such a large size that you need a single sign on solution, you won't be worried about sub domain cookies, you'll probably be looking at a single sign on service, such as facebook, google, openid, or you'll roll your own saml2.0 solution, a CDN will also be able to provide a solution to do cross domain cookies as well.
Someone else can speak to authority regarding SEO.
Build your site the way you find aesthetically pleasing, and deal with the scaling issues when you come to them.
Edit: I did think of one advantage of using www.example.com You can cname www, whereas you would not be able to cname the example.com.
Since the article covers the reasons for www domain, I'll not repeat that and look at other side instead:
It's mostly aesthetic - some people think a bare domain looks better.
The www isn't needed and some think is a relic of the past - who even differentiates between the World Wide Web and the Internet anymore? Certainly not your browser which is more concerned with the protocol (http/https) than three random letters tacked on to the beginning of a website domain.
And finally it's extra typing for the user, or speaking - www is actually quite a mouthful when reading out a web address, and don't even come near me with the "dub dub dub" phrasing that some try to use to address this.
Personally I still think www wins it for me - mostly from recognition factor rather than from the technical issues raised in the article (though they help cement this opinion). In the same way that a .com or .country domain is more recognisable as a web address than some of the new TLDs.
Using a subdomain in your website address (of which www is the most recognisable) does have technical advantages as raised in the article - some of which can be worked around - but other than those it's a personal preference so not sure that SO is best place for this since there is no "right" answer.
One thing is clear. You should have one domain variant and stick with it. So redirect to your preferred version (with or without www) so if anyone ends up on the wrong one they are steered right. This just makes sense from a cleanliness point of view and also from an SEO point of view since search engines see the two domains as separate and so you don't want content showing on both as duplicate. Along the same vein, it's best practice to have your webserver listen to both domains to do that redirect and, if using https, to make sure your certificate covers both domains.
We are currently using a third party Drupal distribution that is locked down due to contractual agreement.
What is the best way for us to add forms to our site that will post to a web service?
Options we considered are:
Deploy another open distribution (core) that we can add forms to and link from the third party site.
Paying the vendor to create the form for us on that distribution (expensive, long lead time).
Any other options?
It's hard to say without actually knowing the details of your contractual agreement.
With drupal a distribution is a set of modules and configuration that lies in the profiles subdirectory of your drupal file system.
So you can add additional modules outside of that by adding them to the sites/all/modules directory.
That way they are not actually part of the distribution but you can still use them.
So for example you can add a custom module that has the forms & web service posting to sites/all/modules and it won't impact the distribution at all.
However if your contract says something like you cannot modify your drupal site/configuration at all then I think you're pretty stuck in a crappy contract.
If you are in a contract where it is expensive & takes a long time to do something that sounds relatively straight forward (again I don't know the details but a form that submits to a web service is generally pretty straight forward) but you aren't allowed to go outside of them to do the work you're in trouble.
Deploying another site just for a form or a couple of forms doesn't really sound like a good idea.
If they belong on the existing site they should be part of the existing site.
If the contract really does exclude you from adding your own code to the site at all it comes down to discussing it with your website provider.
Surely if you aren't allowed to modify the site then there should be a clause that covers you in the case that they don't complete work in a timely fashion.
I have been asked to oversee the development of a handful of sites. The people running the show want it so that if you sign onto one of the sites, then you are automatically signed onto the rest of them.
One of my buddies who is a great programmer says there is no safe way to do this, is he right?
I had an idea that the main site (parent site) could host the daughter sites as sub domains, with each site having its own unique domain name.
What do you think?
Yes, it can be done. However, it won't be a trivial solution but will be a very expensive project that requires an extensive set of skills. Companies typically try to achieve this by establishing internal solutions themselves but tend to fail as complexity increases.
What you are trying to accomplished can also be done as a service. You may want to take a look at the following webpage:
http://www.covisint.com/web/guest/about-identity-services
Hope that helps!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We have written a software package for a particular niche industry. This package has been pretty successful, to the extent that we have signed up several different clients in the industry, who use us as a hosted solution provider, and many others are knocking on our doors. If we achieve the kind of success that we're aiming for, we will have literally hundreds of clients, each with their own web site hosted on our servers.
Trouble is, each client comes in with their own little customizations and tweaks that they need for their own local circumstances and conditions, often (but not always) based on local state or even county legislation or bureaucracy. So while probably 90-95% of the system is the same across all clients, we're going to have to build and support these little customizations.
Moreover, the system is still very much a work in progress. There are enhancements and bug fixes happening continually on the core system that need to be applied across all clients.
We are writing code in .NET (ASP, C#), MS-SQL 2005 is our DB server, and we're using SourceGear Vault as our source control system. I have worked with branching in Vault before, and it's great if you only need to keep 2 or 3 branches synchronized - but we're looking at maintaining hundreds of branches, which is just unthinkable.
My question is: How do you recommend we manage all this?
I expect answers will be addressing things like object architecture, web server architecture, source control management, developer teams etc. I have a few ideas of my own, but I have no real experience in managing something like this, and I'd really appreciate hearing from people who have done this sort of thing before.
Thanks!
I would recommend against maintaining separate code branches per customer. This is a nightmare to maintain working code against your Core.
I do recommend you do implement the Strategy Pattern and cover your "customer customizations" with automated tests (e.g. Unit & Functional) whenever you are changing your Core.
UPDATE:
I recommend that before you get too many customers, you need to establish a system of creating and updating each of their websites. How involved you get is going to be balanced by your current revenue stream of course, but you should have an end in mind.
For example, when you just signed up Customer X (hopefully all via the web), their website will be created in XX minutes and send the customer an email stating it's ready.
You definitely want to setup a Continuous Integration (CI) environment. TeamCity is a great tool, and free.
With this in place, you'll be able to check your updates in a staging environment and can then apply those patches across your production instances.
Bottom Line: Once you get over a handful of customers, you need to start thinking about automating your operations and your deployment as yet another application to itself.
UPDATE: This post highlights the negative effects of branching per customer.
Our software has very similar requirements and I've picked up a few things over the years.
First of all, such customizations will cost you both in the short and long-term. If you have control over it, place some checks and balances such that sales & marketing do not over-zealously sell customizations.
I agree with the other posters that say NOT to use source control to manage this. It should be built into the project architecture wherever possible. When I first began working for my current employer, source control was being used for this and it quickly became a nightmare.
We use a separate database for each client, mainly because for many of our clients, the law or the client themselves require it due to privacy concerns, etc...
I would say that the business logic differences have probably been the least difficult part of the experience for us (your mileage may vary depending on the nature of the customizations required). For us, most variations in business logic can be broken down into a set of configuration values which we store in an xml file that is modified upon deployment (if machine specific) or stored in a client-specific folder and kept in source control (explained below). The business logic obtains these values at runtime and adjusts its execution appropriately. You can use this in concert with various strategy and factory patterns as well -- config fields can contain names of strategies etc... . Also, unit testing can be used to verify that you haven't broken things for other clients when you make changes. Currently, adding most new clients to the system involves simply mixing/matching the appropriate config values (as far as business logic is concerned).
More of a problem for us is managing the content of the site itself including the pages/style sheets/text strings/images, all of which our clients often want customized. The current approach that I've taken for this is to create a folder tree for each client that mirrors the main site - this tree is rooted at a folder named "custom" that is located in the main site folder and deployed with the site. Content placed in the client-specific set of folders either overrides or merges with the default content (depending on file type). At runtime the correct file is chosen based on the current context (user, language, etc...). The site can be made to serve multiple clients this way. Efficiency may also be a concern - you can use caching, etc... to make it faster (I use a custom VirtualPathProvider). The largest problem we run into is the burden of visually testing all of these pages when we need to make changes. Basically, to be 100% sure you haven't broken something in a client's custom setup when you have changed a shared stylesheet, image, etc... you would have to visually inspect every single page after any significant design change. I've developed some "feel" over time as to what changes can be comfortably made without breaking things, but it's still not a foolproof system by any means.
In my case I also have no control other than offering my opinion over which visual/code customizations are sold so MANY more of them than I would like have been sold and implemented.
This is not something that you want to solve with source control management, but within the architecture of your application.
I would come up with some sort of plugin like architecture. Which plugins to use for which website would then become a configuration issue and not a source control issue.
This allows you to use branches, etc. for the stuff that they are intended for: parallel development of code between (or maybe even over) releases. Each plugin becomes a seperate project (or subproject) within your source code system. This also allows you to combine all plugins and your main application into one visual studio solution to help with dependency analisys etc.
Loosely coupling the various components in your application is the best way to go.
As mention before, source control does not sound like a good solution for your problem. To me it sounds that is better yo have a single code base using a multi-tenant architecture. This way you get a lot of benefits in terms of managing your application, load on the service, scalability, etc.
Our product using this approach and what we have is some (a lot) of core functionality that is the same for all clients, custom modules that are used by one or more clients and at the core a the "customization" is a simple workflow engine that uses different workflows for different clients, so each clients gets the core functionality, its own workflow(s) and some extended set of modules that are either client specific or generalized for more that one client.
Here's something to get you started on multi-tenancy architecture:
Multi-Tenant Data Architecture
SaaS database tenancy patterns
Without more info, such as types of client specific customization, one can only guess how deep or superficial the changes are. Some simple/standard approaches to consider:
If you can keep a central config specifying the uniqueness from client to client
If you can centralize the business rules to one class or group of classes
If you can store the business rules in the database and pull out based on client
If the business rules can all be DB/SQL based (each client having their own DB
Overall hard coding differences based on client name/id is very problematic, keeping different code bases per client is costly (think of the complete testing/retesting time required for the 90% that doesn't change)...I think more info is required to properly answer (give some specifics)
Layer the application. One of those layers contains customizations and should be able to be pulled out at any time without affect on the rest of the system. Application- and DB-level "triggers" (quoted because they may or many not employ actual DB triggers) that call customer-specific code or are parametrized with customer keys) are very helpful.
Core should never be customized, but you must layer it in somewhere, even if it is simplistic web filtering.
What we have is a a core datbase that has the functionality that all clients get. Then each client has a separate database that contains the customizations for that client. This is expensive in terms of maintenance. The other problem is that when two clients ask for a simliar functionality, it is often done differnetly by the two separate teams. There is currently little done to share custiomizations between clients and make common ones become part of the core application. Each client has their own application portal, so we don't have the worry about a change to one client affecting some other client.
Right now we are looking at changing to a process using a rules engine, but there is some concern that the perfomance won't be there for the number of records we need to be able to process. However, in your circumstances, this might be a viable alternative.
I've used some applications that offered the following customizations:
Web pages were configurable - we could drag fields out of view, position them where we wanted with our own name for the field label.
Add our own views or stored procedures and use them in: data grids (along with an update proc) and reports. Each client would need their own database.
Custom mapping of Excel files to import data into system.
Add our own calculated fields.
Ability to run custom scripts on forms during various events.
Identify our own custom fields.
If you clients are larger companies, you're almost going to need your own SDK, API's, etc.