I work for an agency that has been responsible for maintaining a client’s .net 3.5 website for a number of years along with another agency. Work is farmed out by the client to both agencies on a pretty much ad-hoc basis.
The site is quite old and has a structure and deployment process to match. The site is setup that developers have local copies of the sites. There is a staging environment, where client feedback and approval happens, followed by the live environment. There are a number of scenarios where work from one agency will be on the staging environment awaiting approval, and changes from the other agency need to go through staging, approval and deployed to live without the original changes being affected. Most of the time we get away with it but it’s far from ideal as not all conflicts can be resolved.
Up until recently we had still been on Sourcesafe but have moved over to Subversion and are running into many more scenarios where work is overwritten. This obviously isn’t a fault with subversion, rather that the locking of projects and files in Sourcesafe served as a good indicator to developers from both agencies that someone was working on that project or file. The process previously was that you checked out a file from sourcesafe and kept it checked out until changes went live (acknowledge that this is a rubbish process hence the desire to move away from sourcesafe and such a model)
The trouble is that even though we know that the way we do it now is bad, I’m at a bit of a loss as to how to restructure the overall site and deployment process to make it “better”. Some ideas we’ve pondered are:
Separate dev, test and live branches in subversion so we need to commit and build the appropriate branch before deploying (not really sure how to make that work)
Single repository for both agencies but a separate staging environment for each. Staging environment could then reflect the changes assigned to each agency
A separate instance of the staging site for each branch
Any suggestions of next steps or examples of similar situations and solutions from the SO community would be greatly appreciated!
Thanks
Joel
I would recomend:
Use git, its really very good for working out how to merge changes.
Have seperate staging enviroments for each company, then, once changes are approved, merge (carfully) into a final staging environmet that only exists to help sort our merging issues there, then push to live.
Also make sure both agencies know who's working on what and try to wait for the other agency to finish working on part X of the app until the other has finished, in the end this is the best solution, a little bit of comunication.
Related
Context: switch from Pantheon
We are currently hosted with Pantheon, an opinionated platform, and we liked their workflow (code up from dev to live, content down from live to dev) and used it with their multidev environments (i.e. easy cloning and pushing all around). - After 6 years they're changing their pay structure for the first time, which includes making multidev prohibitively expensive for just one site.
Usage: multidev for feature branches
We use multidev for having feature branches. For example, one might be a proposed re-design of a page - that way I can keep working in one instance without polluting the dev environment with a half built feature, while working in another to keep hammering out minor fixes and improvements and push those through to dev, qa and then live.
Much later (when the feature branch is finally done) it gets merged with the recent version and pushed to dev, qa, and then live.
Goal: new flow
I need to either come up with a way to mimic this workflow that is easy enough that it actually gets done (manually setting up subdomains and migrating a copy of the site, etc. seems like a lot of idle work) - or replace this one with a different sane workflow.
It's a custom WordPress site with one to a few devs working on features, plus QA, PM, etc. who need to be able to preview the feature branch before it's even allowed into the dev environment.
Good day Experts,
I need to implement subversion on our WordPress websites.
I have never worked with Subversion before. I have however read-up on it and understand the principles.
We have a Development environment consisting of only one server hosting multiple (about 10) WordPress websites. Then we have a Production Environment that consist of 2 servers, one hosting only the WordPress Files, and the other hosting the WordPress databases. The production Environment is the live environment and we want to completely stray away from making any changes directly on here before it has not been tested via the Development Environment.
I need to implement subversion to basically track the changes on the development environment (obviously with functionality to roll back to a previous version if something goes wrong) and then to make it quick and easy for the team to publish to the Production Environment without having to use FTP – may I add that the sites is about 6GB in size on average. Also as it is the design and development team that is going to work with this it would be nice to have a GUI to work from. (I think they are going to give me grey hair if I need to train them on using console commands.)
Our hosting provider supports SVN and Git. I only have been looking at Git and like I said I understand the principles.
But what I cannot get my head around is how to implement this in our environment. Keeping in mind that this is WordPress Websites and that the Production Environment consist of 2 different servers. Like how do I push the database over to the production environment to a different server than the files?
Sorry if this is maybe stupid questions, but like I said I have never worked with any form of subversion before.
If anyone can send me in the right direction on how I could implement this. It would really be much appreciated.
Thanks in advance.
We are a small team of 3 developers. We have a mix of classic ASP code and ASPX pages. All the code is contained in one solution with multiple projects. We are currently not using any VC software and have just install TFS 2013 and want to move to using its VC. Our current environment is setup as follows.
Development environment - new code or changes to existing code.
Test Environment - once the code from development passes unit testing, it is moved here to allow users to test changes.
Staging Environment - this is a mirror of production. once the users have accepted the changes in test we migrate the code here to test and make sure it works against the mirror copy of the database(sql).
Production Environment - code is not modified in this environment.
All of this is done manually and now that our staff has grown from 1 to 2 to 3 developers over the last 6 months we need to make use of version control. What we are not sure of is how to implement this same environment using TFSVC. Do we need to install TFS in each environment and have the 4 separate copies of the code and then how do we migrate the code between each environment using TFS. We need help and suggestions on how to set this up. We want to keep it simple since there is only 3 of us.
Normally you would have one TFS server that holds the sources for all of your environments. Many people implement a branching strategy to support different versions of source code deployed as part of different releases or in different staging environments.
Many people treat TFS as a Development Tool and as such it ends up in the development "network". We recommend people to treat TFS as a production server though, it contains your source code (Intellectual property and an large investment in knowledge and tme) and you might also use it to hold your Product Backlog (which could contain sensitive information on where your company wants to move in the future). If you were to lose any of them it would be a great loss. So make sure you treat the TFS server as something holding value and implement a proper backup & restore and disaster recovery procedure.
Helpful links:
ALM Rangers Planning Guide
ALM Rangers Version Control Guide (aka Branching Guide)
I am used to working in a team that uses Web Forms and VS Source Safe, so procedure would be something like:
get latest version at beginning of day and before checking out.
check in all files at the end of the day, and notify team not to upload.
when finished the page and ready to upload, take a backup, just upload your files and check in.
the team was small enough that it was manageable.
Since you precompile in MVC and Web Applications, it is not possible to upload the site whilst pages in development are checked in.
What is the normal procedure for deployment in small/medium/large companies?
Thanks.
There is no normal procedure, although by rule-of-thumb it generally gets more complex and convoluted the bigger the company.
Consider your own process, if there is nothing wrong with it, then don't change it.
If you need to expand your team, consider a more collaborative way to manage code and deployment. Deployment sucks and nobody wants to do it manually over and over, verbally telling people you're uploading and not to is even worse > consider a build server such as TeamCity or TFS and setup a deploy process that manages this for you.
Consider moving from SourceSafe to Subversion, GIT, TFS etc.
Research ALM across the web (there's lots of good shared knowledge on blogs), but again, consider your need first, and think about if any changes will be actually cost effective and gain you productivity.
I'm interested to find out what would be the good way to make changes to production database and source code in web application (ASP.NET, SQL Server 2008).
A little bit more details, we develop on local machines, and then we need to transfer the code and database changes to production (pretty much standard story).
At the moment we do it in the evening, change the database directly from management studio on production server, and then just overwrite the existing asp.net code (copy/past).
You're talking about Release management. What you're asking about is a big subject with a LOT of different answers. The best solution for you is not something we can tell you. There are trade offs to consider.
For example, what you're describing is a very basic release management process that would be considered an "immature" process.... It does not take into account rollback plans, versioning, separation of concerns, proper testing, or any of a hundred other factors that a "mature" release management process involves.
A mature process is very good, but if you don't have the resources, it's not feasible.
To get to the point, I don't think you question can be answered fully here. I'd suggest starting to research "change management", "release management", "Application Lifecycle management", and "Applicaiton Development Lifecycle". I'll have a few good starter links for you in a minute.
Just a forewarning, though, you are asking a question that's going to open your eyes and your world in ways you probably haven't considered. There are things like automated builds to consider, tools to do it for you (high priced, free, and everything in between)
http://en.wikipedia.org/wiki/Release_management
http://en.wikipedia.org/wiki/Application_lifecycle_management
A few simple options for JUST what you're asking about can be found here:
http://msdn.microsoft.com/en-us/library/7hd4c0x3(VS.80).aspx
Also, since you talked about source code without mentioning which source control you're using, I need to say... if you're not already using source control, you need to. You'll wonder how you ever lived without it once you start using it.
Depends on whether it's the first deployment of a new app, or an update to the app.
For small updates, record all your database changes as sql scripts. You must strictly enforce that all changes to development are applied as sql scripts. Put the scripts in source control. Deploy the update by running the scripts on production.
For new apps you may have thousands of scripts. You can't run them individually. Consolidating them into a master script takes too much time. (although you still want to check EVERY script into source control). In this case you reach a milestone in development then FREEZE the development database, and declare it a baseline. Use the database tools to generate a master script(s). Deploy production by running this script(s). Manually create data scripts for your lookup tables to keep it separate from junk dev data.
Avoid a database copy. Avoid changing by hand through the GUI. Scripts are the way. How you go about collecting the scripts, consolidating to master scripts, generating the scripts, etc is another story.