We are small wordpress focused web development company planning to migrate to OpenShift by RedHat.
My goal is to have production environments (apps) in the cloud and most of the development is done in local laptops using OpenShift origin and then deployed as staging apps to private OpenShift installation and when approved back to cloud replacing original app. It would be extra if all team could be able to edit app simultaneously in the dev version of the app (in the cloud).
The problem I noticed is that web development often requires many edits when tweaking CSS and such and commits to OpenShift takes more than 10 seconds.
Hot deploy (https://www.openshift.com/kb/kb-e1057-how-can-i-deploy-my-application-without-having-to-restart-it) speeds up process a bit, but not enough.
Another option is to SCP/SFTP to local OpenShift installation and edit files bypassing git and build process. That causes git to be off sync, but it can be fixed (http://druss.pp.ua/2013/11/synchronize-openshift-application-after-update/)
How ever, process isn't that smooth as i hoped it to be. Any improvement ideas?
I prefer to keep my plugins & themes in git. That allows me to run a copy of my wordpress site locally for development, then add my changes into git, do a git push, and have the production site updated. This would require a minimal change to your files you have now if you used the OpenShift quickstart. I can provide details if needed.
Related
I am looking to stand-up a development/test WordPress website in Azure alongside our production site and am looking for any best practices I can find.
The idea is to keep the environments the same having both sites on the Azure PaaS but having different URL's to be able to access them. And having the databases be separate (to ensure we don't mess up anything in production)
Example...
Production -- http://companywebsite.com
Development -- http://test.companywebsite.com
Has anyone attempted something like this before? It would be fairly simple if the development was being done locally but we need multiple (non-developer) users to be able to access the WordPress admin panel on the test site and be able to install plugins and such to test.
Thanks in advance!
have you tried deployment slot?
When you deploy your web app to App Service, you can deploy to a
separate deployment slot instead of the default production slot when
running in the Standard or Premium App Service plan mode.
https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Update:
Seems like you can also config wordpress to aware of staging environment.
http://www.wpbeginner.com/wp-tutorials/how-to-create-staging-environment-for-a-wordpress-site/
I have just taken over the management of a business-critical WordPress site.
Currently there isn't a development server or any source control. I would therefore like to get this setup and was just after a bit of advice on the best workflow.
Development will be done on one machine initially, but the development server must be hosted so geographically dispersed stakeholders can view the site and sign-off changes before it is deployed to the production server.
I have used Subversion previously, but I would like to make the jump to Git and was thinking about using a private Bitbucket repository.
My questions are:
Does this sound like a sensible solution?
What is the most efficient/robust method of getting the code from the local machine to the production server (via the development server) while maintaining version control?
Many thanks!
Yes you can do the development initially on your local machine, commit the changes, push them to the bitbucket with Development branch. You can have read only access to your stake holders in order to sign off the changes from Development in the remote to Production in the Remote branch.
Since you used SVN before and trying to migrate to GIT. You can use the git svn command to migrate from SVN to GIT.
Or you can use the tool SubGIT tool for a stress free migration from SVN to GIT.
I'm a web developer thinking of moving work on our largest client's site to a Git workflow, but I am new to Git and am not sure how to integrate it with our client's .NET servers and IT folks.
The current workflow is: a co-worker and I work cooperatively on local versions of the site files, which we then push via FTP to the client's development server (accessible via VPN). Once the changes on their dev are approved, we have to catalog every changed file and email that list to our client's IT team. One of their team then manually pushes the changed files from dev to their production server. We are not allowed any access to the production server, as there are enterprise apps on it as well as the public-facing web directory.
A bit more awkwardness comes from the fact that the client's IT guys are all .NET developers and we are a Mac shop. Fortunately, the site files are 99% HTML/CSS .aspx files, so they are easy for us to work with. Occasionally, the IT guys post an .ascx form control we have to incorporate, but for the most part changes travel from us to them.
As the site has grown, the labor of cataloging changed files has become a bottleneck and a point of potential failure. I want to automate deployment and provide revision tracking and rollbacks. From our side of the router Git looks like the way to go.
But what do I propose for the client side of the workflow? My understanding is Git is not native to .NET or IIS. I doubt I will be able to persuade our client's IT guys to install and use a new toolset. Their main job is enterprise app development, and I get the feeling they don't exactly live for the thrill of pushing our web updates live.
I am not sure if i understand you right. But git with .NET is pretty much the same as in other technologies.
Here is a git extension to use with Visual Studio:
http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c
Github is full of .NET projects.
I can't give you a advice to how to propose it. But git is definitly not a problem to use in VS or generally in .NET. They just have to switch.
You can also integrate git in your Team Foundation Server.
http://www.microsoft.com/en-us/download/details.aspx?id=30474
Git-TF is a set of cross-platform, command line tools that facilitate sharing of changes between TFS and Git. These tools allow a developer to use a local Git repository, and configure it to share changes with a TFS server. Using the tools, changes made in TFS can be pulled into a local Git repository, and changes made in the Git repository can be checked in to TFS. These tools can be used by individuals or teams collaborating using Git.
This way you could use both. TFS and Git for the same project. I think this could be a solution.
Currently we deploy compiled ASP.Net applications by publishing the web site locally and emailing a zip file to the system administrator with a (usually) lengthy set of instructions for deployment. This is because the first time we deployed an ASP.Net application to a customer the dev and test IIS instance were the same, and we were unable to deploy the site twice to the same machine. This set the tone for deployment on all subsequent projects.
I am now evaluating our deployment methods and am looking specifically at the built in deployment tools; specifically I'm looking at custom installation tasks and using as much of the standard installer functionality as I can (mostly the user interface).
Secondly, I'm looking at merging deployments and automatic updates.
How do you go about deploying sofware in your organisation? What tools do you use, and what problems do you come across most frequently?
We have dedicated DEV, TEST, STAGE, and PRODUCTION servers.
We also have a dedicated build machine which runs Cruise Control.
Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks.
To deploy to development, the code is first retrieved from SVN and built, then the "Precompiled Web" folder is copied to the development web site, and the web service project is copied to the development application server. Cruise Control is also configured to "tag" the source code before the build starts so we can reproduce the build at a later time, or branch from the tag if we need to do a hot fix.
To deploy to QA, the files are copied from the development machines to the QA machines.
Likewise, to deploy to Stage the files are copied from the QA machines to the Stage machines.
Finally, to deploy to production, the files are again copied from the Stage machines to the Production machines.
To configure each environment, we have a custom tool which is part of each environment's Cruise Control task that modifies connection strings, "debug=true|false", "customErrors=Off|RemoteOnly", and other environment-specific settings.
So each environment can be deployed with a button push from the Cruise Control dashboard.
One caveat is that we currently have the production database password configured in the Cruise Control config file...it would be nice move it elsewhere!
Lastly, let me add that even though our production machines are in a dedicated hosting facility, the servers are accessible from our Cruise Control machine, which makes it very easy to do a production deployment. The only manual step is to encrypt the web.config files and remove the "AppOffline.html" file that Cruise Control puts up.
Let me know if this helps, or if you have any questions.
Thanks!
A couple things that I have done is the following:
1) Use a Web Deployment Project in order to compile and clean the build as well as handing web.config section replacement if the config changes between environments.
2) Use NAnt to do all of the building, archiving, and copying in a repetitive manner.
The Web Deployment Project ends up creating a MSBuild file which can be used in place of NAnt; however, I came from a Java background and used Ant all of the time so NAnt is my preference in .Net. If you add in the NAnt Contrib tasks, you will be able to deploy not only the files but also handle items such as your source control (incase it is not part of the default tasks) and Sql Script Execution for changes.
Currently I use both of the options together. I have my NAnt build file call the Web Deployment Project through MSBuild. With the configuration manager setup for each environment, it allows me to manage the web.config section replacements automatically and still have fairly decent control over my copying and archiving of a release.
Hope this helps.
We use web deployment projects, and the VS 2008 projects to create an .msi from the output of the webdeployment & other projects. A normal windows app called 'setup' is used to do a lot of the db creation and preliminary stuff, rather than trying to customise the setup projects with custom steps. It is a lot easier to do this yourself than trying to customise the MS code. This windows app then calls the correct .msi files that the user needs.
Team foundation build runs every evening to rebuild the solution and copy everything to a 'Release CD' directory which anyone can access and do testing on the latest 'release'.
To be honest TFS build is a bit overboard for a small team like ours, and I only use it because its what I am used to.
In a previous company we used this http://www.finalbuilder.com/ and I can recommend it for ease of use and for the amount of software supported.
1) Build project with MSBUILD
2) FTP files to Production Environment
3) Copy / Paste manually to each web server
For intranet sites, we use CruiseControl in conjunction with SVN to have the site rebuilt automagically.
Theoretically you could extend this model over a VPN if you could map a drive remotely to a client's intranet. Or a more quick and dirty solution might be to use a tool like SyncBack to sync the remote folder containing the compiled DLLs for the site.
Deploy Web Applications Using the Copy Web Tool
Text from Microsoft Training Kit Book Web Based Development
Web Setup Projects are useful if you are providing a Web application to many users (for example, allowing people to download the application from the Web and install it). If you are responsible for updating a specific Web site for your organization, it’s impractical to log on to the Web server and install a Windows Installer package each time you make an update. For internal applications, you can edit the Web application directly on the Web server. However, changes you make are immediately implemented in your production Web application, and this includes any bugs that might be there. To enable yourself to test a Web application, you can edit a local copy of the Web application on your computer and publish changes to the production Web server using the Copy Web tool. You can also use the Copy Web tool to publish changes from a staging server to a production Web server, or between any two Web servers. The Copy Web tool can copy individual files or an entire Web site to or from a source Web site and a remote Web site. You can also choose to synchronize files, which involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited. The Copy Web tool cannot merge changes within a single file; only complete files can be copied.
Does Microsoft offer a tool where you can deploy a web application to multiple web servers in a load-balanced environment/web farm?
My team is looking for a tool, preferably from Microsoft, where we can deploy our web application from development environment to production environment automatically.
If I understanding what your asking for your looking for a build server, to my knowledge Microsoft don't offer one, but some to take a look at are Team City, Hudson(requires a plug-in), and CruiseControl.net.
Basically they work by pulling from your source control building your application and running your tests. They all support scripting that will allow you to build then deploy to your servers. This can be set up to run nightly, weekly, etc. you can also set it up to monitor your source control for changes and build anytime it sees a change
The only one I've used is Team City, the install was easy, and depending on how many build agents you need it's free.
If your just looking to build and deploy from VS Another option is creating an NAnt script and running it from VS as an external tool.
For a good over view of Build servers check out this SOF question cruisecontrol.net vs teamcity for continuous integration
The Web Deployment Team blog at Microsoft has some reasonably useful information, and have a deployment tool you could try...
In the last environment we setup we used TeamCity for all our builds and deployments (Which is basically to say we wrote MSBuild scripts and automated them with TeamCity). In short we had the following 5 build configurations:
Continuous Build - Automatically rebuilt our product upon every check-in. Running all the tests. This build did not deploy anywhere
Nightly Build (Dev) - Automatically build and deployed our product to the development web server (no server farm). We build would run the tests, update the development database, shutdown the Dev IIS web site, copy the necessary files to our web server, and restart the site
Test Build - Like our Nightly build only it deployed to our test environment and it wasn't scheduled so it had to be manually started by logging into Team City and pressing a button
Stage Build - Like test only deployed to a web server that was externally visible to our customers sot that they could validate the application. Also, only run on demand.
Production - Created a zip file of our product that the deployment team could install on our production web servers
So I guess what I'm suggesting is that you use TeamCity and then write build scripts in such a way that they'll deploy to your Web Farm. If you want examples I could supply you with the pertinent portions of our build scripts
** One more thing: we check in our web.config files and such for each environment into subversion and then part of the build process is to copy and rename the appropriate config file for the environment. For example, web.prod.config => web.config in our production build
I believe that Sharepoint does this.
File Replication Service ( e.g. DFS Replication ) is a typical and very good choice for doing this.
Your changes are synced between member servers at the file system level.
Sharepoint does this automatically when you deploy a solution package.