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.
Related
I have now a working Website that I have deployed to the IIS on my local machine using Visual Studio 2013. I can access the website successfully from other machines in my office and in neighboring offices. I have even had others check the access from geographically remote locations, and still been successful. The access method is to put my machine's IP Address and add the name of the application, ###.###.###.###\name, into the address bar of a browser.
The next step is to promote it to production. We are not using Azure, so the tutorials for promotion to production I have found aren't useful, nor are we using 3rd party providers.
The method I have conceived is as follows:
Have an admin directly login into a company server
install the database software
install Visual Studio
install IIS
copy the local machine's db to the server db
copy the locally deployed files to the server
admin login into Visual Studio
deploy the site on the server in the same way it was deployed on the local machine
use the server IP or update the host file on all networked computers to map the IP to an appropriate name (or the local network has a local DNS we can update)
This would allow me a DEV environment (the VS IDE), a TEST env (locally deployed version), and a PROD env (the version deployed on the server).
I don't see any reasons why this wouldn't work, maybe a bit tedious, but workable.
Is this method ok? Am I missing anything critical?
No, this is an altogether inappropriate way to push a build to a production environment.
Your source code should be stored in a source code repository. You should have an automated, continuous build server pull from the repository and complete the build in a dedicated environment that is itself under change control. The build should include the generation of installation files, e.g. a click-once deployment package. From there you can have an admin run the deployment package, or, ideally, you'd push it automatically with a tool like Octopus.
The above, honestly, is the bare minimum for a commercial web site. There is much, much more you can do to make things even more robust, e.g. blue-green deployment.
Note that none of this involves installing development tools like Visual Studio on your server. The server should stay as clean as possible, running the fewest applications that you need, to minimize any sort of attack surface and to keep the machine running efficiently.
Dont Put Yours Machine IP, Decompilers Can Take It And BruteForce Your IP To Remote Acess Your Machine.
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.
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.
Can anyone provide insights of using Jenkins for automating deployment under controlled and uncontrolled enviroments. We have different environments - dev/qa/uat/prod and currently we are using batch files that call msbuild/nant scripts to deploy on web and DB servers (web farm). Developers only have access to dev/qa and production support will deploy on uat/prod. Prod. support will get the source code from SVN tag folder and run the batch file to deploy the application.
By using Jenkins, is it possible to eliminate the step of prod. support team getting the script from SVN by running the jobs using their credentials via url. And what is the general practice using source control and CI tool for deploying applications.
My recommendation is to reserve Jenkins for just building the software. That way the user of Jenkins only have access to development and perhaps QA systems.
To decouple the build system from the process that deploys the software I recommend the use of a binary repository manager like:
Nexus
Artifactory
Archiva
In that way deployment scripts could retrieve any version of a previous build. The use of a repository manager would enable your QA team to certify a release prior to it's deployment onto production.
Finally, consider one of the emerging deployment automation tools. Tools like Chef, Puppet, Rundeck can be used to further version control the configuration of your infrastructure.
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.