I have developed 9 multiple websites/stores in one magento installation. On DEV server it is ready and working good. Now my client wants to launch first 3 websites in next month, then after we will make some modifications in other websites based on feedback from first 3 websites. Then launch other websites one by one.
One thing which I am worried about is how we make modification and further development. Because magento files and db is one installation, if we launch first three which means we are launching whole system, and if we make DEV work in live site that is not good because if anything breaks etc. LIVE sites will go down.
What is the best and logical procedure in magento to launch multiple stores one by one. What approach we can follow for such situations.
Please help, thanks!
To my eyes, the fact that you have 9 different websites/stores running off the install is of minor importance. You will encounter the same issues that any dev / live Magento set-up will encounter. At the point the site launches you will need to create a second copy of your database / code for use as a development environment. With regards to the code, I would hope that you are using some kind of VCS such as Git or SVN, if you aren't you should seriously consider it.
The database is the slightly trickier side of things. It is also going to be the issue exacerbated by the fact you have 9 different websites, since you will have a lot of different configurations. There will likely be 3 different types of configuration changes to be made.
1.) A setting that needs changing for the live websites.
2.) A setting that needs changing for a future website to be launched.
3.) A setting that needs changing in order to make your development site work.
The 3rd type is the easiest to deal with. You can simply change them in the database and forget about them. These will include things like setting the base_url values in core_config_data.
The 2nd type should ideally be made with migrations rather than through the UI. If you are using Source Control these migrations would be kept in a branch that will get merged into your master branch at the point you wish to launch the website they effect (at the point the code is merged, you may have to do some tinkering with the version numbers based on how you deal with type 1.
The 1st type can be handled in one of two ways, a migration is a favourable option as it means all installs of you code dev / staging / live can be kept in sync. If needs be, simply ensuring you update your dev database at the same time as the live one, would suffice.
Some of the things you need to change won't necessarily be the easiest things to achieve through migrations, but doing so should prevent any errors from arising whereby you forget to update a single value on one of your servers.
Related
My drupal 7 site takes more.. time to node add (node/add) and update (node/edit). Please anyone help me to reduce the time of node add and edit
Normally I'd do this:
Try disabling modules you installed recently. Or revert/switch off new functionality. I assume when you say takes more.. time you compare it to some time in the past when it was better. Try to recall what were the changes to the website configuration or modules set since then and roll them back one by one.
On your local copy of the website enable Devel module and look at the amount of queries executed while adding or updating a node. look at the most slow ones. It may lead you to some more narrow question.
The last resort I'd say - profiling code with xdebug but I'm not sure how deep you are with PHP development and debugging. This one requires skills in configuring your web-server, and using a PHP IDE or at least an xdebug profile reader (e.g. webgrind)
Try installing fresh Drupal 7 on same server (i.e. create staging sub-domain) and see will on it adding/updating also take long time. If so, problem is with server obviously.
If it's fast with fresh Drupal then problem is on your site - try turning off modules one by on (again on staging domain preferably) until it starts working at normal speed. Must be that some module is causing the problem.
There is a web app. Let's say I want to add a feature. I can write some code, test it locally, make sure it works - then publish it so it is available to the public. Some features though are very complex and not that easy to be written, tested and shipped the same way.
I want to make it so certain feature I am currently working on is not available to the public even though I publish the app.
Let's say I want to add a custom breadcrumb feature to the app (just for one page to keep it simple). I can write a block of code surrounded by some IsProductionReady variable maintained somewhere in Config file - then once I am done I can set IsProductionReady to True - so now it shows up.
I also want to be able to switch to any other features / changes and publish them without affecting any code, without showing any signs of Breadcrumb feature development. When I am done with the feature I want to be able to just make so it is available to the public.
What are the best practices or strategies to maintain a certain state of a feature? What is the best way to structure it?
If you're using Git, it's better to have a separate branch for each new feature, then after the branch being tested and approved you can merge them into your main develop branch, run another regression test (because different features may interfere each others functionality) and then move it to the Production branch.
Take a look into these urls, I presume you can find your desired scenarios in them :
http://nvie.com/posts/a-successful-git-branching-model/
http://martinfowler.com/bliki/FeatureBranch.html
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
I would have separate branches on Github between both and keep the structure the same. When your feature is ready, merge to the production branch.
I'm curious how other people have approached this. Our group has been given the directive of implementing an internal website utilizing Joomla. We've set up a dev server for the person who is responsible for maintaining the site, and a production server. We're using IIS and the current version of Joomla.
I can sync the two with Akeeba Backup Core and Kickstart, but it seems an "All-or-Nothing" choice. It works, but if she's doing work on, for example, the look and feel of the site, but just wants to sync content, that doesn't appear to be doable.
I feel that someone out there must have tackled this goal before, but web searches seem to turn up people running dev/prod on the same server but in different subdirectories, or ignore the "all-or-nothing"ness of the issue, going for the "Do all at once" approach, which doesn't seem practical. Content changes frequently, but not-so the look/feel.
We've been doing this for several years now. We use a dev server and a prod server. When we make content changes on dev, we use phpMyAdmin to copy the content table from the dev db to the prod db. In some respects, it's still an all-or-nothing approach, because we have to copy the entire content table at once. This means you can't have some pages still in development when you do the copy. In other respects, it still a piecemeal approach, because we can copy individual tables such as modules, menus, etc. But again, it's ALL modules at once, ALL menus at once, etc. There is a way in phpMyAdmin to copy an individual page or item from a table in dev and put it in the corresponding table in prod, but it's a little cumbersome. It works, though.
As for design elements (images, css, template changes, etc.) we do the same thing, but the copying is done manually by ftp from one server to the other. Obviously this is the same method for things like pdf files on dev that need moved to prod.
In summary, this method has worked fairly well for us for a long time. But it's limitation is that you must realize you're copying an entire table at once.
The positive of all of this is that when we have pages that are in development, I have leverage over the content people to hurry and finish their work because one unfinished page can hold up the entire site!
This workflow dilemma has come up a few times for me.
You mention changes to look and feel, and that is simpler really, if it is just template changes. It is quite simpler to pull down an Akeeba Backup of the live server, kickstart it onto a local server, work on the template files, and then upload the updated template files to the live server.
That said, if it is more than CSS and HTML tweaks to existing files, it can be a more involved process.
Personally I've not found a silver bullet for this sort of thing, but with some forethought and planning it is not too bad.
Sorry if a similar question has been posed before. There are a lot of deployment questions but none seemed to address my problem.
Anyway. I'm working with asp.net, C# and using Visual Studio.
The Organization I'm working in is changing rapidly. There are a lot of projects coming in the pipeline that will require multiple code changes and iterative deployments over the next few months. While working, these changes are always 'on the forefront', so sometimes I have to code certain parts of the same program multiple times.
Since these projects are all staggered, I can't just make one sweeping change all at once; I have to deploy and redeploy the same program multiple times, using only the changes that are required for that deployment.
If this is confusing, here's a simple example:
Application is being used on an Intranet. This application calls our Database, using Driver A.
There are two environments, test and production.
Certain Stored procedures have to be called with parameters that register 'Test' to allow certain other applications to run even with bad data (for testing purposes).
When deploying applications, these stored procedures have to be modified, removing Test parameters
We have an Operating System upgrade, allowing us to move to a much faster Driver B, but requires changes to be made to the code to use Driver B.
So that's two wholly different deployments where some code must be changed for Deployment 1 and other code must be changed for Deployment 2.
Currently I'm just using notepad for an overall change list, regular debugging break points and a multitude of in-code comments, and then I manually slog through the code to make sure that everything is changed. With hundreds of thousands of lines of code over multiple files, classes, objects, etc. this gets pretty tedious, as well as there being a good chance of missing something (causing it to break) or pushing wrong changes (causing it to either break or allow bad data).
Is there a tool that could be used to help in this situation? Preferably one that I can discern what needs to change for Deployment A and what needs to change for Deployment B? I'm also open to hearing other schools of thought as well (tips are definitely accepted!)
Sure, I understand your problem.
I would suggest a couple of things
Installers : Why don't you think of installers, there are loads of installers i.e Install shield, Wix, MSI installer.
These installers will give you flexibilty to update files which you need to update, i.e. Full Control.
But you need to choose the best of them, I have worked around MSI and Wix a lot, so I know this can sort your problem, however its your call.
Publish : I haven't played around much with this, I have just done website publish. However I know it does wonders, so try it also.
Here's the situation:
A while ago, I created a back-end interface for adding/modifying/deleting items in a DB. It was created as an individual project, and we are still using that particular instance of the code. I will call this "version 1".
A little while after I completed this, I duplicated the code and integrated it into a much larger project. I copied all of the DB tables that were used in the original project's DB into the DB that this project was already using. I also had to duplicate the front-end here, but it's the back-end that I'm concerned with. The requirements for this interface (I will call this "version 2") were a bit more complex, so I had to keep working on it and also make some modifications to the DB tables.
It is essentially 2 branched versions of the same interface. However, version 1 has not received much attention since version 2's conception. Some of the changes I made in version 2 were not just new features, but improvements/bug fixes that are relevant to version 1. I should have made these changes on version 1 as well, but unfortunately I didn't. Going forward I will need to make improvements to both versions, and some of these improvements will apply to both of them.
I would really like to merge the 2 interfaces somehow, as I'm quite sure that it will reduce my workload in the long run. Frankly, I would like to abandon version 1 and adapt the version 2 UI to version 1's DB.
My first instinct is to transport everything to a user control that has a "version" attribute. The version would then be used to hide/show the controls that are or aren't relevant to that version, and it would also be used to determine what DB queries/stored procedures to use. The issue with this is that this whole interface spans across 5 pages. A few of these pages are opened up as dialogs from another one of the 5 pages. I suppose that I could simply have one div per interface, and then when !IsPostBack, I can set the Visible property of each div according to a querystring variable. However, this seems like it would be awfully messy and it would be a LOT of code and markup on one page. I guess alternatively I could have 5 user controls, but this just seems like an odd design.
Are there any other viable solutions?
i've been maintaining 4 products with nearly identical interfaces:
they started from one project
got cloned and branched
i've been slowly re-merging them
The best suggestion i have is try to some up with a UI that works for both, and switch both to using that.
After that i have a project-local settings file, which defines which features should not exist in one or the other.