# svn上傳流程 為了確保維護svn代碼的正確性，指定svn上傳代碼流程如下： **開發人員開發** 　開發人員本地分支-->取得svn最新代碼(根據前一天的最后tag合并)-->代碼開發-->提交分支 　合并時注意事項，對于沖突的文件查看是不是自己本地正在修改的文件，不是的話就按照主線覆蓋，否則按照本地，最后解決沖突問題(不好操作的話就備份好自己本地代碼，將svn代碼拿過來，仔細看下沖突問題)，這樣在匯合的時候就可以按照自己的分支來開發(注意防止別人先合并)。 **開發人員代碼合并** 　開發人員本地svn主線-->取得svn最新代碼-->從本人分支合并到主線svn主線-->提交到svn主線(**要謹慎處理**) **每周值班人員代碼取得** 　取得上線列表-->檢查svn開發人員提交日志-->取得最新代碼-->值班人員打標簽tag-->本地編譯打增量包 　打標簽的工作在檢查后提交sa前進行，每次提交給sa都打個tag，這部分工作最終是自動化，將每i次打包的文件放到固定目錄下供sa使用，在打包后注意一些目錄和文件不要打包進去，一是占用空間，二是會沖掉網站文件。 * * * * * # 大中小型企業上線解決方案 ## svn目錄阻止結構說明 $ tree ~/data/svnapp/ ├── branch *← 分支，為測試時使用，幾天以后上線的項目必須開分支，測試需要本分支通過，主線合并到分支通過，才能合并到主線進行測試* ├── tags *← 版本記錄時候使用* └── trunk *← 主線，與正式線相對應，當前不上線的文件不允許提交* 3 directories, 0 files ## 小型公司上線案例 程序多為php程序，直接通過FTP直接上傳代碼到線上服務器，隨時隨地上線更新。 **此上線方法存在的問題** 1. 開發不經過測試人員測試，用戶訪問頁面刷新后頁面即改變，對用戶體驗比較差，如果開發寫錯了代碼造成的影響就更大。 2. 大概50%以上的故障直接和開發程序代碼有關 3. 網站出了問題一般是運維人員的問題(例如宕機)，但這種情況下，問題大多數可能由開發人員引起。 **解決方案** 1. 開發人員需要在個人電腦上搭建lamp環境測試網站代碼，并且在辦公室或者IDC機房有測試環境。 2. 代碼上線規定時間，例如：三天上線一次，如網站需要經常更新可每天下午17點上線(根據網站業務性質而定，原則是影響用戶最小) 3. 代碼上線之前需要備份，網站程序出了問題方便回退，另外，上傳代碼時盡可能先傳到臨時目錄，完整后使用`mv`命令移動到網站目錄。 4. 有運維人員管理上線，對于代碼的功能性，開發更在意，而對于代碼的性能和服務的穩定，運維更在意，因此運維上線這樣更加規范科學。 ## 中型企業上線解決方案 > 規范運維人員操作步驟，制定統一的操作腳本、備份文件名稱、備份文件路徑。使操作人性化、統一化。