{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 时光不老，我们不散 的问题《What is your favorite web app deployment workflow》','https://www.manongdao.com/q-459041.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
We are currently using a somewhat complicated deployment setup that involves a remote SVN server, 3 SVN branches for DEV, STAGE, and PROD, promoting code between them through patches, etc. I wonder what do you use for deployment in a small dev team situation?
相关问题
- How can I set the SVN password with Emacs 23.1 bui
- If statements in .htaccess files, to enable passwo
- ClickOnce updates all files. Why?
- SVN+SSH checkout over VPN using tortoise SVN, Smar
- Mercurial compared to private branches in SVN
相关文章
- Override env values defined in container spec
- Is there a version control system abstraction for
- Intermittent “SVNException: svn: E175002: Connecti
- IntelliJ Subversion Authentication Required Dialog
- TortoiseHG and hgsubversion (Windows): “no module
- Incompatible JavaHl library loaded
- What is a good way to deploy a Perl application?
- TFS vs. JIRA/Bamboo/SVN [closed]
When i worked in a small dev team (small meaning me, another programmer and the boss), it was quite the chaotic mess. However we found that Assigning a "gatekeeper" type of process worked for us.
The gatekeeper was the person who had done the most work on the app (in this case, i had 2 projects i developed from the ground up, he had like 4).
Basically, whenever he had to work on my projects, he'd notify me that he was doing work, i'd make sure the repository was up-to-date and buildable, then he would pull down, make his changes, then commit. He would inform me that it was done, i would pull down, build and deploy. If there were DB changes we had a DB Change folder with all the scripts that would correct the DB.
It's obviously got a lot of holes in it, but the process worked for us, and kept us from building over each other.
I personally work locally (development), adding/fixing features and when I think it's ready I commit to trunk (production). On production server I just do an svn update.
trunk for development, and a branch (production) for the production stuff.
On my local machine, I have a VirtualHost that points to the trunk branch, to test my changes.
Any commit to trunk triggers a commit hook that does an svn export and sync to the online server's dev URL - so if the site is stackoverflow.com then this hook automatically updates dev.stackoverflow.com
Then I use svnmerge to merge selected patches from trunk to production in my local checkouts. I have a VirtualHost again on my local machine pointing to the production branch.
When I commit the merged changes to the production branch, again an SVN export hook updates the production (live) export and the site is live!
A simple trunk branch contains the most current code, then cut a branch whenever we go live. This seems to work pretty effectively. You can easily go to the previous branch whenever the current branch that you cut for the live system fails. Also, it is easy to fix bugs on the branch that is currently live, and since the branch effectively dies when you cut a new one, there is only ever 1 real branch you need to work on (and then merge fixes from there to the live branch).
We use release branching - this seems to be more efficient for us than the feature branching we were doing.
Don't make different branches for the different environments.