I am in process of making first Drupal 7 website and for that searching for the web hosting. And I found that, several hosting says 1-click Drupal installation. But as I was searching the net for standard practice of site development, many sources explains Develop the site on local environment and then transfer to the web server (which includes, transfer of database, and whole drupal with modules) which is quite convincing that you develop locally and transfer to web so it start working there as it was working on locally.
On the other hand, what is the use of 1 click drupal installation on web server, I believe it will install the fresh core drupal, so from again initially I have to start developing, installing each module so, starting from square 1.
So, which is the BEST practice for making web site live, shall i develop locally first or develop directly on web server?
Simultaneously, what is the best practice about maintaining site, I read that, there should be One live site where visitor will come, Second Test site which is similar to live, One local site, So what is the standard practice for this, and how to maintain?
Very thanks in advance.
In my previous answer in point 2 i outline 4 servers: DEV, STAGE, QA and PROD. this is usually the process on kind of "biggish" company where lots of people might be working in infrastructure, development and qa department. This said, if you are not working in a complex environment, you might just have 2 drupal installations, one for testing , on DEV (e.g dev.mysite.com) and one live (eg.mysite.com). The different url can be arranged from you cpanel or personal panel in case of a shared server.
They might run on the same server, however the dev site is the one you will be working on while creating the site, then you will clone the dev and make it live once the site is ready.
You will keep the dev site as a space to test new features, fix bugs, test updates of module or core files. Once these new features are implemented, or bug fixed, you will replicate the same steps on the live site.
GIT is a version control system: it allow you to keep track of the code you are working on, you might want to create 2 branches: DEV and MASTER.
You will be working on DEV to create the site or update files or fix bugs, and you will merge to LIVE and pull on the live server the code once it's stable. I hope this clarify a bit.
1) one click installation process are usually offered on shared servers, they then might have lower performance and memory limit that your local lamp set up. It is the good to check what is the version of PHP and MySQL that runs on the server, as well as max upload file limit or connection time. I prefer start working locally and then publish on my server, BUT if you install on your server first you will have a good idea of how drupal will perform in the real world, then you can always clone the site and db on your local, and also you will avoid the ugly surprise of trying to move your site from local to your server and find out bugs or migration issues.
2) in enterprise dev environment you might have 3/4 steps, DEV ("wild west") STAGE (release candidate) QA (quality assurance server) PROD (live site). You usually sync (eg with GIT) your local to DEV or STAGE , than you push to QA, then if it's all good to PROD
Related
wondering if you can help me with the following.
I have a new server in my office, with Windows Server 2008 R2, i have 2 developers working here now, i have just installed WAMP on the server and running, i would like that each of the devs to have their own instance in the wamp, i mean if within www i have N quantity of Projects.
Programmer A gets access to some projects only, also the Databases.
At this point i know how to setup the wamp to be accessed in the LAN using Vhosts, but i have no clue how to setup specific privileges.
Could not find anything on the web on that issue.
Can I suggest another method.
As WAMPServer is intended as a developers tool anyway, you install WAMPServer on each developers PC. You make sure the config on all PC's is the same as the Server version.
For an existing project i.e maintenance/upgrade you give them the source and a database backup. They develop this locally and when its ready you take the source and a database backup to your WAMPServer on the Server.
For a new project, they develop it locally and then when its ready you move the project to the Server.
This would be much simpler and would leave the Server version for UAT or LIVE, whatever you are using it for.
Of course there are better solutions involving source management etc, but as a fairly simple and low maintenance solution, this would work.
I am in a situation where the current web server is a production environment and there is no development environment. It is running Joomla on an IIS Web Server and is an Intranet site with all of the security, IP restrictions, Certificates, and whatever else required to run an enterprise level Intranet site.
I am wondering what I can do to set up a development environment to work within (preferably using some type of version control).
I have full reign over the IIS server, and I have had a co-worker set up a VM clone of the current system to work with, however the security is making it difficult to work with and set up.
I would like to not use Visual Studio as I don't believe I have a license for it; however I can get it if need be. I would like to stick with Notepad++ if at all possible.
Thank you.
If you're wanting to literally take the site content out and be able to edit and work without any of the security restrictions of the production environment, there's a couple of ways you could do it. However, it's going to depend on what DB the system is running with.
Joomla, regardless of what web platform it is running on, is coded in PHP, so you don't have to worry about getting visual studio. You can use Notepad++ as normal.
Option 1 - IIS Clone
If you can take a SQL backup of the database, you build a from-scratch box with IIS. You'd need to add the PHP drivers to IIS to do this. Go to Microsoft's site for more info:
PHP for IIS
Option 2 - Apache Port
You can make an Apache box using WAMP to run, if you're using a Windows machine. PHP is PHP, on any platform, so it should work without modification.
The tricky bit will be the database, depending on your situation. If the database is MySQL, you can import your database backup and be good to go, after changing the config files for the Joomla site.
If the site used MSSQL, it's a little trickier. You'll need to install an MSSQL PHP plugin to get this medthod to work. There's plenty of instructions online on how to do this, it's a case of finding the right one for your implementation.
I've a VM (#1) with installed SP 2010 and SQL Server 2008. It suites our needs in terms of load and capacity. In case of breaking down we can revert it to the snapshot.
The development process still goes on.
The question is what is good approach for updating the production VM?
Variant 1:
Have a copy of production VM (#2)
When the iteration is finished (development->testing->fixing) and we ready to make update we swap the VMs (#1 <--> #2)
Testing VM #2 becomes production and #1 becomes testing one.
" + " : We go live with fully tested solution.
" - " : Mechanism for sync up between VMs is required.
Variant 2:
Develop, test and fix on the production VM
Publish changes when we are ready.
" + " : We don't need mechanism for sync up between VMs
" - " : Crashes can happen more often.
Any suggestion will be appreciated.
TIA
Do NOT do your development on the production VM. SharePoint is very easy to break during development and you will more than likely bring down your production environment at some point. The risk is basically too high.
Do your development on a separate system. Package your solution/changes properly as a WSP - test it on another system (in between your dev environment, and basically a copy of production). Once it passes all testing on your staging server, deploy the WSP to production.
Swapping systems is a pain in the arse when it comes to SharePoint - you have Alternate Access Mappings, IIS Bindings etc. to worry about - and takes more time and effort than simply just uploading a new WSP and hitting "deploy" (obviously, after testing on your stating server).
It really depends on "what" you are developing:
Content only
It is often easier to do this on the production machine. The standard publishing framework should be sufficent to hide changes from standard users.
Or you could use the content deployment features of sharepoint to move it from the dev farm to the production farm
Or you could use the content deployment tool
Webparts, simple components
In 2010, these should be done as sandboxed solutions (if you can get away with it), then they are very simple to upload/change on your prod environment. Build on your dev enironment, then upload through the sharepoint webpages.
Complex components
Things that require a farm administrator to install on the server (jobs, complex web parts, etc), should be developed with visual studio on your dev box, then moved to prod in a fully tested way. Try having a testing/stage environment.
A combination of all of the above
This usually depends on how much risk your client is willing to expose themselves to, say for instance, if it is a brand new server there is not much risk in taking down users of the system.
I would not recommend installing visual studio on a PRODUCTION SharePoint server
So, I'm about to embark on a fairly lengthy, time consuming project that could net me some good results/rewards - and I'd like to give everything the attention and focus it deserves. I will be the sole developer, and I'm experienced in that capacity (about 13 years in the industry). I've just never had to be responsible for EVERY choice so I'd like to throw this out there for some feedback. This is going to be a website.
Dev Tools on Win x64 workstation:
VS2010
SourceGear Client
FileZilla
UltraEdit
SQL 2008 Mgmt Studio
I will have my own DB Server machine also, which will run SQL 2008 for both the web DB and will host the Soucegear repository DB.
I'd like to have an automated build process that includes
pulling the latest code from the repository
checking it against rules (ala FX Cop)
compile the code
running a series of tests against the new compilation (unit tests?)
Any suggestion on tools to do these tasks? Should I just write & execute scripts to do certain steps?
Backups! - I'd like the source code repository and web files, graphics, media, etc. for the site backed up regularly. I use Mozy for my own personal backups - is there something more suitable for this kind of backup? Windows Home Server or something like that perhaps?
Lastly - what am I not thinking of that needs to be on my radar? For example, I plan on using jQuery but only have limited experience with it - any good javascript tools besides VS2010? How to most web devs test their sites across the plethora of browsers available? Should I use minify-ing tools for the web content - which are best? I've built plenty of web sites & applications before - this is just my first real "commercial" venture and I'd like it be founded in solid practices.
I, too, am a single developer and use much the same tools as you...
Couple of things...OK...it grew to more than a couple...
I like to use UltraEdit sometimes for editing my javascript files...as it has some features that VS2008 lacks...not sure abt VS2010...mainly a function list to aid in navigation of the file.
I also use JavaScript Lint to check the syntax of my javascript files...you can integrate it into UltraEdit...my choice...or VS...or both.
I use subversion for source code control...Visual SVN for the server and Tortoise for the client...both free
For backup I recently started using DropBox...you can point DropBox to the folder that holds your files and it will sync whenever DropBox starts (and it will keep the files synched on multiple machines...so if you have an offsite machine...you're covered if something happens at your main development site).
If you'll be using LINQ at all...I'd recommend getting a copy of LinqPad It's free, but you can pay to get "intellisense"...the examples included are fantastic learning tools.
When using jQuery...look for plug-ins that do what you're looking for...
We are starting with Sharepoint development with a team of three and are currently setting up our development environments. We would like to avoid installing a Server 2008 for each developer, thus a single terminal server has been setup, using Remote Windows to start a VS2008 instance on each developer's machine. Now we would like to separate developers' testing environments (i.e. a different site colletion per developer), but have realized that the assemblies would need to be installed into GAC to show properly on the site. But since there is AFAIK only one GAC, developers wouldn't be able to test their stuff independently.
Is there any way we could create separate testing environments without installing a bunch of 2008 Servers?
So you're all going to remote in an fire up Visual Studio and be compiling stuff and restarting IIS, etc?
You're going to be stamping on each other's toes.
A wiser choice nowadays is to use Hyper-V (or some other virtualisation).
We use Windows Server 2008 on our laptops, and use Hyper-V to run our dev environments. We then have a dev environment (sandbox) each, and these have VS2008, SVN, Nunit, etc.
Our code is tested against each other thanks to CruiseControl on the only shared Hyper-V.
This has been great for us... we distribute the load, we can work on the move, we don't step on each others toes and if we need to do a demo we can switch Hyper-Vs and demo from the demo Hyper-V (branched from the dev one early on so that the environments are known).
Go virtual and don't look back.
PS: I've just seen your comment about one server... just put Hyper-V on that and run 3 instances. That's also what we do ;)
I don't know about installing the server on everything, but this sounds like an ideal task for Virtual Machines rather than physical ones- where I work we using VMWare a whole lot for this kind of work and it does very well.
It's also useful to be able to roll back to a snapshot when it comes to testing installation processes and so on.
No. In addition to the GAC there are all the SharePoint files in the 12 hive, such as features and site templates. It's not worth what you save on server costs.
(Of course if you don't use the GAC, but deploy to the bin folder, and you don't touch anything in the 12 hive, you can give each developer their own web application on the same server. But this approach puts a lot of restrictions on what they can do. It's still not worth it.)
Virtual machines will work, but they can be slow to develop on. For instance, you'll need to restart the application pool for every GAC deploy - which means a pause of maybe 15-60 seconds to reload the application, (depending on the hardware). This will become annoying.
Virtual machines work better for test and production, where you don't restart the application so often.
I recommend a physical server for each developer. This will minimize the code-deploy-test cycle time, and make sure they don't have to worry about stepping on each others toes.
You are on the wrong track with Terminal Services - its just not going to give you any separation.
A lot of people do recommend developing on W003/2008 server directly, and it does simplify some things like remote debugging.
I prefer the more traditional method of using VMWare to run virtual machines. These can be running on a local or remote host. Remote debugging is a little more complex to setup but still possible.
Finally - if possible then deploy to the bin dir rather than the GAC. This will make it much easier to deploy automatically after compilation.
The contributors are right that there are lots of stumbling blocks to multi-developer single server environments.
Number one developers will be trying to attach to the same Web Application process w2ps.exe so creating separate Web Applications on different ports is a must unless you are prepared to share time debugging. How to setup a development environment for sharepoint 2013
The second problem is when you try to collaborate and use shared components/features. Having a desire to work separately is debatable, I believe that the team developers should be collaborating and sharing so combing work is desirable to ensure seamless integration into a single final solution and that no work is duplicated. The multi-developer single server environment works perfectly until you try to collaborate 'One common mistake is to have one “development server” used by all team developers. Unless team members are working on totally unrelated components and never need to do common things such as restart IIS or attach a debugger to an IIS process, this type of environment generally doesn’t work well.' http://technet.microsoft.com/en-us/magazine/dn145990.aspx We made this mistake through lack of experience and knowledge, but once you make it it's possible to work round it.
My first attempt to share features was to copy developer 1's project into developer 2's solution and add a reference to it in developer’s 2's project and add all the features to developer 2's package. Deploying this works fine for developer 2, until as I discovered if developer 1 detaches their solution from the debugger it retracts the solution based on the duplicated solution id from the farm and therefore from each developer's web application. Therefore developer 2 has the rug pulled out from underneath them. Although this is a part solution and seemed to work for a while, it took me a while to work out what was happening and what combinations of dev 1 and 2 deployments make each other’s work and not work.
So I found a better solution. Under the project properties in Visual Studio under SharePoint tab there is a combo box called 'Auto-retract after debugging'. This by default retracts the solution when the developer stops the attached debugger and pulls the features out from underneath the other developers. Unticking this box prevents the retract and leaves each developers individual solutions deployed at farm level and on reattaching to the debugger just replaces the solution with minimal fuss.
In my experience recycling the IIS application pool is so fast other developers don't even notice, but with a larger team than 2 this might become more prevalent, so perhaps someone else could add their experiences. I also guess unless the other develops try to attach at exactly the same time that the recycle is happening it'll be fine, so is a really small chance of having a cross over time, and simply detaching and reattaching will fix this if it is ever experienced.