I am trying to come up with an optimal workflow for updating my web application running on play framework.
I use the start script to launch it but what is the best practice for updating the code so that it is as seamless as possible for the users?
In an Apache + PHP application often it is sufficient to drop new *.php files in the directory and in many cases the change is not even noticeable for the user.
Could you share your workflow for doing that with play framework?
The play framework is very different from using something like php on apache. Php is interpreted by Apache when a page is requested by a user. So all you need to do is change the file to update the site. With java however (unless you are using .jsp files and even sometimes then) the code is bytwise compiled and the webserver needs to load it and its libraries at start up. What this means is that just replacing newly compiled files will not work. You need to restart the web container or get it to reload the application to pick up the changes. This is always going to be noticeable to any users that try access the site at the same time as the reload is being completed.
You could have a web server (doesn't have to be Apache) that points to your current play installation as a proxy and bring up a new version of it in parallel and then switch your proxy webserver point to your new version and turn the old version off. This is probably the easiest way to do this and could be scripted.
Another way is to just have a web app that redirects the the user to the app and doing a parallel change similar to the one above.
Both of these options require some setup and coding to get them to work seamlessly. However the work is probably worth it as once you have it setup rollouts to production become very easy.
Related
I'm looking at some (PHP) Frameworks, and I just noticed this in the Laravel documentation:
Like most web-development frameworks, Laravel is designed to protect your application code, bundles, and local storage by placing only files that are necessarily public in the web server's DocumentRoot. This prevents some types of server misconfiguration from making your code (including database passwords and other configuration data) accessible through the web server. It's best to be safe.
I'm familiar with CodeIgniter and CakePHP, as far as I know, these two frameworks don't do this. Should you really split it up and place your core logic outside of the webroot? In my experience, most clients use shared hosting and are not able to change their VirtualHost settings.
What kind of misconfiguration could you possibly do that would output your passwords? When developing, should you really do this?
Yes, keeping only those files which should be publicly accessible in DocumentRoot is a best practice for web application security. Consider:
Every file which is private would need a rule configured with the web server to explicitly block it.
Anyone adding files to the project needs to consider web server security settings. Simply keeping the files in separate directories makes it obvious what's public. And developers don't need to change security configurations.
Separating executable code and static files is a good practice anyway.
Not blocking access to PHP scripts can cause unintended consequences. For example, you may have a script to update some DB records when run manually at the command line, so someone simply guessing a script name can run it over the internet.
Monitoring for and cleaning malicious code written to the public directory is much easier if the real application logic is elsewhere. See Wordpress breakins for an example.
CakePHP supports this - see deployment:
CakePHP applications should have the document root set to the
application’s app/webroot. This makes the application and
configuration files inaccessible through a URL.
There are some queries for which we need resolution before we purchase sitefinity 5.0 license. I would really appreciate if could get answers to these
What are the recommended guidelines to setup the sitefinity project in the source control? If there 4 to 5 developers working on the project, what should be the starting point in setting up the initial codebase? Do every developer has to create the sitefinity website and DB on their dev-boxes?
Is it recommend to setup a common DB for the sitefinity website where all the dev-machine would be connecting to do the development, if not what is the alternative approach?
Is there any online documentation available related to build and release of sitefinity web applications, other than publishing from within the visual studio?
Thanks
Gaurav
We've been developing with Sitefinity since version 2, with multiple developers.
To answer your questions specifically:
Have a single developer (ideally your lead dev) create a clean sitefinity visual studio solution on their local machine. Check it into your source control repository and have each additional developer pull down a copy from there. You're now all in sync.
In terms of database location, two approaches work - either have each person run a local database, and in the web.config setup the connection string location as . (i.e. local). That way no one needs to check out the web.config to run it. Otherwise use a common development/testing server for the database. We've found the easiest way is to each have a local DB, unless multiple devs are working on very specific tasks together at the same time.
I have not seen any online documentation related to building outside of visual studio. If you have TFS or a MS build server, it should work fine as well.
In general, there is nothing 'special' about Sitefinity's architecture that separates it from any other .NET / MSSQL solution. Best practice that falls under these technologies still applies.
My experience with source control has been one of two options. If you are using SQLExpress user instance databases (that is an mdf in the App_Data folder) I've found versioning everything except this database file and the dataconfig.config file in the configurations folder will allow every developer to run their own copy of the website.
from there you can either do some kind of manual merge of the database or just create a new one for deployment.
This option works best if your developers are simply working on features, and don't need to be working on an actual website, modifying content that has to keep in sync.
Alternatively, if they do need to work with live content and it all has to be the same, create the database in a shared server they all have access to, and version everything (since the connection string should be the same for both).
This works best if your developers are doing work to support existing content as opposed to say creating modules that manipulate the database (creating tables, columns, etc), because keep in mind with this method, everyone will be accessing and modifying the same database.
Personally, my preference is option 1, because it allows each developer full control over their environment. the source could then be merged and shadowed to a staging server, so that the main site content is only affected by this one instance.
I hope this is helpful!
I have an app on the App Store that needs to have its resource data files updated periodically (every 2-3 months). So far, I've just been deploying a new version of the app to the App Store every time I need to do this, but the fact that I have to wait a week or two for the changes to become live is cumbersome.
Theoretically, I was thinking of creating a new "version_control.txt" resource file which tracks the version numbers of every other resource file. Periodically, the app would check its version_control.txt against a version up on some web server, and then download any files that need to be updated.
Do there exist any frameworks or SDKs to handle all of this for me, or do I have to write everything myself? Is there a better solution?
You can't update the resources in your app bundle without updating the entire application. However, there's no problem with having your app retrieve resources from a web server and save them in your app's Documents folder. From there, it's simple to have the app look for its resources in the Documents folder before looking in its own bundle.
I don't know of any frameworks that manage resource versions for you. There's not a lot of work involved, and each app likely has its own requirements, so I'm not sure that a framework would help that much. If your web server supports it, you could request the resource file(s) each time your app runs, but add the if-modified-since header so that you only download a new copy if the version on the server is newer than the one your app already has.
I also had similar problems. I had tried to download some custom files from my ftp domain but that really didn't work very well. Not only I had to pay for the bandwidth, the users weren't very happy about it. The coding complicated considerably. Now, I've decided to update periodically via AppStore. The users are more satisfied since they see updates, but they don't understand is that only a couple of resources have been updated.
PS: I'm not aware of any SDK or framework for it. But you don't need it, you just need to download some files...
Im new to website development and design so apologize in advance if the question is redundant.
I have a program where a client, using a URL string fetches a XML file from a webserver. This would be no problem right if it were a simple URL with no security or no CMS (like Joomla) involved: Just put the exact URL string and the client gets the file from the web server, done.
But, how would the process work if the URL is on my site hosted on GoDaddy and using a Joomla CMS?
Im trying to understand how the same process of fetching a file works on a hosted server using a CMS. Since I just made the transition from my site being on my school's servers to having a Joomla website Im hosting on goDaddy.
I mean where would I put the file if I also want the file to be accessible only if the client authenticates itself first. Just to be on the safe side. I mean is this how normally things work in mobile apps? I have a client program thats a iPhone app and within the app I have a XML file which is used as a data source for my UITavleView, but I want to check some URL to see if an updated version of the XML file exists. My app side programming is mostly done, now Im trying to learn the server side things I need to do to make this process happen with Joomla and my own hosted site
I donot understand how would the process work in that case. I mean, what are the things I would need to do on the server side to and the client side to make this possible?
Please help me understand or if you could point me to some links where these steps are illustrated...or if you could give me some Google key words I can search for to learn about this process.
thanks a lot
The fact that you have a CMS does not generally change how you access a file within the file structure of your domain unless the CMS protects certain directories. In this case, Joomla does not so you can directly access any file you wish. Depending on the sensitivity of the information you are trying to retrieve, you can protect the directory through your domain management panel. If it's not particularly sensitive, the authentication can be done by the app since the URL you are accessing can be easily hidden from the user.
It seems like that would be the simplest solution since the app will have access to user information by nature of where it resides.
I've just inherited a CF app from a customer who uses a shared CF hosting provider. I'd like to introduce better processes including the ability to stage app changes that I make for their review. (In the past, they would upload changes and cross their fingers.)
Their app lives in a folder under the webroot. Let's call it "/app". I'd like to create a sibling directory named "/appstaging" where I would publish the latest code. The obstacle is that the hosting provider lets you set paths for custom tags and mappings but not per CF app. The existing settings all point into the /app directory so if I need to make changes to tags, CFCs, etc., I can't test these without affecting the live app. What I want is CF to let me set per-app tag paths and mappings. From what I've read, CF8 lets me do this but the customer is using CF7 (I'm pushing for them to upgrade asap). In the meantime, is there anyway to workaround this or does a smooth way of staging changes have to wait?
(I am currently experimenting with ways to detect which app I am based on using GetCurrentTemplatePath() in application.cfm. The idea is that any code that refers to other files using mappings would use a different mapping. I haven't done enough work there though to know if this will all work out.)
Any ideas or input are welcome. I should point out that the app and its dev env is not very "modern." There are no frameworks involved and no things like ant used for build/deployment. The customer's budget is extremely limited so I'm not looking to convert the app whole-sale but I do need to find cheap ways to get some process in there to keep things sane.
This is a serious, but wacky, suggestion: use a second hosted account.
Write up a cost-benefit analysis of having live and staging servers, and compare that to the cost of a second hosted account. The second account doesn't need massive data allowances, etc, and ought not cost as much as the live account.
Additionally, calcuate the cost of revising the code base to allow live and staging on the one account and compare that to the cost of a second hosting account.
Remember that you wont need the second account once your real upgrade is complete.
I expect you'll need to do something like defining the custom tag paths in a config file that gets loaded into the application scope. But that'll require some serious code refitting.