統(tǒng)一部署平臺(tái)
Jenkins svn部署
idc環(huán)境
lvs負(fù)載均衡linux virtual server
正式lvs
測(cè)試lvs
網(wǎng)站上線
分組上線(分兩組上線)
上線時(shí)間1小時(shí)
上線周期看服務(wù)器數(shù)量情況,一般一天就可以搞定
用java自動(dòng)化打包工具 ant
上線注意事項(xiàng):
都放在svn上
代碼
配置文件
分組上線
本地辦公環(huán)境
idc測(cè)試環(huán)節(jié)
真實(shí)環(huán)境
都必須完全一樣
除了ip不一樣其他都要一樣
java代碼上線的方案
開發(fā)包 ...dev.war
測(cè)試包...test.war
配置管理員 (一般屬于開發(fā)組,也有可能屬于架構(gòu)組)sa上線人員(系統(tǒng)管理員)
php上線的方案
php上線測(cè)試環(huán)境,放置真實(shí)環(huán)境,然后做軟連接過來
java上線
分組平滑上線,大公司的標(biāo)準(zhǔn) 每日獨(dú)立訪問ip超過100萬
從負(fù)載均衡器上摘掉一半服務(wù)器
如果前端有dns智能分析,可以分地區(qū)上線
代碼上線解決方案注意事項(xiàng)
上線的流程:辦公測(cè)試環(huán)境->IDC測(cè)試環(huán)境->正式生產(chǎn)環(huán)境,所有環(huán)境中的所有軟件均應(yīng)版本統(tǒng)一,盡量單一,否則將后患無窮
開發(fā)團(tuán)隊(duì)辦公室測(cè)試環(huán)境由開發(fā)組自己維護(hù)
專門的測(cè)試工程師
IDC測(cè)試由測(cè)試人員和運(yùn)維人員參與,叫IDCtest,進(jìn)行程序的壓力測(cè)試,有問題直接反饋給開發(fā)人員,沒問題則直接上線
網(wǎng)站的平滑上線,怎么做到???
正在提供服務(wù)的就提供,后面再進(jìn)來的就不讓進(jìn)來了,這就是平滑測(cè)試
網(wǎng)站資源和程序都是分離的(svn上存放程序代碼),盡可能全量上線(不要使用增量上線),這樣就以svn為主.
如果增量上線的話,很有可能svn就不是最新的代碼,就不一定是對(duì)的
存放所有服務(wù)器的配置文件
開發(fā)小組測(cè)試環(huán)境,辦公測(cè)試環(huán)境,IDC測(cè)試環(huán)境,線上應(yīng)用使用的配置文件都要在svn上
配置管理員
就是開發(fā)和運(yùn)維之間的一個(gè)紐帶,協(xié)調(diào)開發(fā)和運(yùn)維關(guān)于上線的種種事宜
自動(dòng)化部署和上線代碼管理平臺(tái)
python運(yùn)維
代碼變更管理通過svn
業(yè)務(wù)變更管理平臺(tái)
1變更管理制度流程有利于業(yè)務(wù)穩(wěn)定
2保留變更業(yè)務(wù)歷史,便于核查發(fā)現(xiàn)的問題
3故障跟蹤平臺(tái),有利于跟蹤問題的解決進(jìn)度,而不是半途而廢
4相關(guān)常用軟件:
jira mantis可以使用業(yè)務(wù)變更管理平臺(tái)
一些紙質(zhì)的規(guī)章制度要有
pubfree工具,用來解決分多臺(tái)機(jī)器發(fā)布
淘寶自己的
灰度發(fā)布 一般間隔24小時(shí)
一般核心業(yè)務(wù)才會(huì)走灰度發(fā)布
回滾機(jī)制(出現(xiàn)問題的解決方案)
產(chǎn)品上線通知單
技術(shù)部門
產(chǎn)品部門
運(yùn)營(yíng)部門
市場(chǎng)部門等等都要參與
一般由開發(fā)和運(yùn)維參與執(zhí)行
新項(xiàng)目上線通知單....等等
緊急上線申請(qǐng)單等等...
上線的流程...
越往上走,越重視以下內(nèi)容
流程,制度以及方案
1.svn的獨(dú)立模式應(yīng)用
鉤子的應(yīng)用案例
通過ldap統(tǒng)一認(rèn)證
2.大型企業(yè)的代碼發(fā)布
有一些制度流程,邏輯方案
3.業(yè)務(wù)變更
今天課后作業(yè):
1.為中型企業(yè)設(shè)計(jì)一個(gè)代碼發(fā)布的方案.
模型工作經(jīng)驗(yàn)(必須要做的)
2.csvn,git安裝部署(時(shí)間充裕就需要完成)
