I need a web application that can:
Track the files that have changed/been added between dev and a live site
Publish these changes/additions to a live site
Enable rollback to any point
I don't want to build it as I'm sure it's been done before.
What do you recommend and why?
Related
The Google Actions SDK has been rewritten again for version 3 and comes with a completely new developer platform with different ways of working. As far as I can tell, there is no way to migrate a legacy (Actions SDK V2) action to the new SDK and Actions Console experience.
Is there a documented way to migrate to V3?
Is anyone who has successfully migrated able to share their experience and any problems they ran into?
I haven't found any usable documentation on switching versions so my best guess is to start from scratch with a new project, then delete the old one and rename the new one. Is that likely to work?
My app is a simple conversational Action implemented with the actions-on-google#v2.x SDK. I did not use Dialogflow at all.
Progress so far
I've had some partial success by using the new version of the gactions CLI.
I created a new project using the new web console experience then pulled the configuration down from the server. I then pulled my existing project configuration down, edited the files to match the test project, then pushed it back up.
This has resulted in the web console UX changing to match the new experience but there is a residual error that prevents me from testing my app.
Custom actions can only be specified in Conversational Actions projects.
This makes me think that there is some kind of project type in the back-end that determines what should happen in the web console. Pushing a modernised configuration up to the server seems to have changed the UI mode without changing the project type, causing an issue that prevents any maintenance on the old app or any migration to the new version of the system.
Update: A new migration workflow for Dialogflow Actions was just released. This is not relevant to my app because I never used Dialogflow.
I have a small team working on web site project using Visual Studio 2010 and with Team Foundation server 2012.
In order to have proper control on deployment, I would like to implement my dream deployment strategy as shown in the figure ( https://www.dropbox.com/sc/foy5fh7pntreiha/AAB4L4hhbpjcm1zHi6VBLSa6a )
There is no problem for my team to perform the check in/out between their development pc with the TFS server. But I have problem to deploy code from TFS server to targeted web server.
I read many articles talking about build deploy, but for me I don't think I need to do build because mine is not a web application and we basically have all the codes in the targeted web server. We don't need to build the project into dll and then only upload to web server.
I tried using "copy website" feature in Visual Studio 2010, but on the copy website panel, it is always local programmer pc code at the left hand side and the targeted web server on the right hand side.
I wanted this deployment flow because I think this is the safest flow so that no one will accidentally upload the wrong version of code into the web server. Everyone would have no choice but to check in their code(s) into the TFS server before he/she can upload into the web server.
Please kindly help me.
Thanks
Dont do that.
Instead use Stage / Production server, Stage and Master git branches,
Tell them to exclusively work out of stage, you control the merge to master,
use deployhq or similar service to hook into git(github) and trigger automatic deployments.
Much better than VS, much safer. Should a deploy not work due to file error, DHQ will prevent the entire deployment and revert to old state.
I've found a few post on this topic but have not been able to find the best solution.
Attempted to integrate Ionic into IBM MobileFirst (Worklight).
At the moment - I have built a normal Ionic project and moved the WWW folder in the 'common' folder. Also added in the initOptions, main.js and messages.js.
MobileFirst has an awful build process - I hate having to deploy to a mobilefirst development server + preview app for any code changes. I am hoping to get some type of auto reload working within mobileFirst, or at least develop with ionic normally and hav ea job to bring my changes into my worklight project... something that is better than me current situation.
Does anyone have a sample project that actually auto-builds or picks up code changes automatically?
Any and all help is greatly appreciated.
Not sure what do you mean by "auto-reloading"; if you make any changes to the web resources to your project inside the Studio plug-in (in Eclipse) and reload the preview in the browser, it will show the changes.
You are not required to Run As > Run on MobileFirst Development Server for each change. As long as you work on the resources in your workspace, the "auto-reloading" as you call it, should work (make sure you are using the latest available MobileFirst Studio version from the Eclipse Marketplace).
There is also a rudimentary Starter Application that is based on Ionic.
You can download it from here.
There are also several results on the subject matter when searching in Google.
The need to rebuild in order to see changes in your Web components (CSS, JavaScript, HTML) did used to be an annoyance in early versions of what was then Worklight and is now MobileFirst. I forget when the need for a rebuild was removed but certainly in Worklight 6.2 and beyond you now simply need to refresh in your browser.
UPDATE: If using MobileFirst 6.3 you need to ensure that you are on a
suitable patch level. I find that simple refresh does not work in
6.3.0.00-20150106-1717, but if I update (Help->Check for Updates) to 6.3.0.00-20150214-1702 then edit/save/refresh works as
expected.
My personal practice is always to have Mobile Web environment in my project and then choose that from the Console. This loads the application in the browser-based Mobile Simulator that you can tailor to fit your target form-factor. This has a "Go/Refresh" button that immediately reflects your edits.
Alternatively, some folks these days do not use Studio, instead they use the Command Line Interfacer. Possibly this may be more to your taste. You can download it here.
there is a solution with using staff like ionic-cli serve command + symbolic links that will replace common folder.
check here an example https://www.dropbox.com/s/4pvaulo6yo47kb9/lab_7.2.mp4?dl=0
(you just can disable sound, cause i've recorded it in russian) 7-15 minutes of this video
Other option is to organize live-preview yourself using IDE features and/or nodejs
This will work as long as you are working on front-end (mostly non-worklight api) part.
You need to include this lines in the index.html
<!-- ionic bundle & css -->
<link href="www/ionic/css/ionic.css" rel="stylesheet">
<script src="www/ionic/js/ionic.bundle.js"></script>
I'm hoping someone can confirm whether or not the following scenario is an issue with deploying updates to WordPress sites and, if so, do you have a solution on how to best manage this?
The basics:
I have a local development WordPress Multisite project for which I
use GIT and Capistrano to deploy to remote staging and production
servers.
Everything EXCEPT the uploads and blogs.dir directories (in
wp-content) are under version control. Yes, the WordPress core,
themes, plugins, etc are updated locally, committed, pushed and
deployed. This means that I have to login and activate plugins
initially - they are simply installed via the Capistrano deploy
The databases on development, staging and production are different and
I'm not concerned about trying to sync these up
My Concern:
Many updates to plugins and the WordPress core also perform updates to the database when doing an auto update via the admin. I am updating WordPress core and plugins locally on my development install. The code to these updates ends up being committed, pushed and deployed. However, when the code is deployed it is simply adding/deleting/replacing changed files to the staging and production servers. Production and staging are missing any of the updates to the database since this is usually part of the auto update process - eg, deactivate, updated, activate (run any updates to database).
My Questions:
Is my concern about the production and staging servers having the
latest code but missing any database updates required for the latest
code accurate?
If so, does anyone have thoughts on how I can modify Capistrano
deploy code to deactivate/reactivate of plugins? What about changes
in WordPress, eg, 3.2 to 3.3?
If Capistrano isn't the tool for this - and I need to do it more
"manually" by logging into the admin - is there a maintenance mode
tool/plugin that will somewhat automate the deactivation/activation of the
plugins so any updates upon activation are triggered?
Many Thanks,
Matt
Its important to note that you don't need to activate and deactivate plugins when you upgrading the WordPress core from version to version. Here is an explanation from Ryan Boren on why. Depending on the plugin though, some of them may have an upgrade process built into their upgrade - that is, the upgrade of the plugin, not of WordPress. None the less I'll go through your three questions and answer them as directly as i can.
1. Is my concern about the production and staging servers having the latest code but missing any database updates required for the latest code accurate?
Yes, when updating, if there is a change to the database schema, then WordPress will not function properly unless the new schema exists. When attempting to access the admin side of WordPress, if the db version is lower than your WordPress version expects, it will redirect you to a database upgrade page.
WordPress sets a global called $wp_db_version in the /wp-includes/version.php file and maintains each of the migration scripts to upgrade the database incrementally from each previous versions to the next until the version number is up to date, seen here. Here is a simpler list in a FAQ showing how the revision numbers correlate to WordPress versions..
2. If so, does anyone have thoughts on how I can modify Capistrano deploy code to deactivate/reactivate of plugins?
As I said above, you dont typically need to activate/deactivate plugins after core upgrades, unless I suppose the plugin specifically requires that you do so. If the schema changes in WordPress break a plugin, then the plugin developers will need to release a new version. When upgrading that plugin, it will be shut off and restarted, and its those developers responsibility to make sure everything that needs to take place does so.
However you may need to deactivate/activate separately in deployed environments such as yours, since the actual upgrade process is taking place on different machine, and thus probably a different database from that which it will ultimately be used on.
Perhaps the best thing to do would be to have your deployment script hit a URI of a plugin within WordPress, a plugin you would write which would deactivate/activate plugins, or an existing one that already does it.
It's possible some exiting plugins might handle parts of what your looking for, but I take the key component of your question to be automation, and an avoidance of having to log into each environment and upgrade plugins for each one, so developing one yourself that does exactly what you need might be the way to go. Developing a plugin is possible if you make use of the tools WordPress already provides.
activate_plugin()
activate_plugins()
deactivate_plugins()
validate_plugin()
Plugin_Upgrader class (maybe)
Look through the whole /wp-admin/includes/plugin.php file to see what you might find useful. Additionally checkout code that actually handles plugins in the admin side in /wp-admin/plugins.php - just to see how its done. You may want to stop the deactivate_plugin hooks from wiping out plugin configuration with plugins that clean-up after themselves, so consider passing $silent as true when de-activating the plugin.
To make this really slick, you'll probably want to grab get_option('active_plugins') to see which plugins were already activated, and only run your script on those (make sure the plugin excludes itself from the process)
3. What about changes in WordPress, eg, 3.2 to 3.3?
Changes from 3.2 to 3.3 should be thought of as no different from any other set of changes, so everything said here applies.
4. If Capistrano isn't the tool for this - and I need to do it more "manually" by logging into the admin - is there a maintenance mode tool/plugin that will somewhat automate the deactivation/activation of the plugins so any updates upon activation are triggered?
I don't think Capistrano will be doing any of the heavy lifting here - but its certainly not in the way either. You should just need to be able to just hit a URI within the plugin, and that should get things rolling within the application. The important thing is that obviously all those functions need to be available so you cant just run it as in independent script.
Typically I develop my websites on trunk, then merge changes to a testing branch where they are put on a 'beta' website, and then finally they are merged onto a live branch and put onto the live website.
With a Facebook application things are a bit tricky. As you can't view a Facebook application through a normal web browser (it has to go through the Facebook servers) you can't easily give each developer their own version of the website to work with and test.
I have not come across anything about the best way to develop and test a Facebook application while continuing to have a stable live website that users can use. My question is this, what is the best practice for organising the development and testing of a Facebook application?
I hope I understood your question correctly.
What we have is 2 versions of our app, that is two applications defined in facebook.
We have the regular version that runs on deploy, and we have the myapp-test version.
this version runs on the domain myapptest.com (or you can use myapp.local).
In your HOSTS file (%winder%\system32\drivers\etc) define this url and redirect it to your own server on localhost (127.0.0.1).
Now, all you need is a config file on each machine that is not updated via source-control.
The localhost (development) version uses the app_id for the myapp-test, and relevant settings.
The deploy uses the other settings.
Then when you deploy you just need to upload your code.