Change Details

//Migrated from: https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards/4590 // == Context == The current deployment system "wikiupdate" has served well, but it is showing its age. The addition of composer (among other things) have made it insufficient to meet our rising quality standards. The main issue is that on every upgrade of code, the site can break in multiple ways and stay broken until the deployer figures out what broke and fixes things. I am envisioning an incremental rewrite of the system. The architecture loosely mimics WMF's deployment system, although is much more simpler. It should be a two-phase system: update, then sync. In the first phase we will update our code, resolve any merge conflicts and other breakage. Then we deploy in a way that causes minimum disturbance to the site visitors. In case something still breaks (broken code, missing database schema update), there should be easy way to rollback to previous version. Implementation details have not yet been decided. == Narrative == As a twn sysadmin I can update the site with minimum disruptions so that our translators get a better service. == Acceptance Criteria == * Merge conflicts can be resolved without breaking the site * Easy way to rollback to previous version * Handles local patches to core and extensions * Works with composer (as well it can given restrictions) * Can easily support HHVM's RepoAuthoritative mode if we choose to use it * Handles multiple wikis (production, development, sandbox) == Deliverables == * //Enter link to actually done tangible deliverable(s)// **Open Tasks** {{ table query: SELECT Number, Name, Owner, 'Estimated effort (hrs)', 'Task Status' WHERE Type = Task and 'Schedule - Story' = THIS CARD and 'Task Status' < 'Done' ORDER BY 'Task Status', Owner, Name }} **Completed Tasks** {{ table query: SELECT Number, Name, Owner, 'Estimated effort (hrs)', 'Actual effort(hrs)', 'Task Status' WHERE Type = Task and 'Schedule - Story' = THIS CARD and 'Task Status' = 'Done' ORDER BY 'Task Status', Owner, Name }}

//Migrated from: https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards/4590 // == Context == The current deployment system "wikiupdate" has served well, but it is showing its age. The addition of composer (among other things) have made it insufficient to meet our rising quality standards. The main issue is that on every upgrade of code, the site can break in multiple ways and stay broken until the deployer figures out what broke and fixes things. I am envisioning an incremental rewrite of the system. The architecture loosely mimics WMF's deployment system, although is much more simpler. It should be a two-phase system: update, then sync. In the first phase we will update our code, resolve any merge conflicts and other breakage. Then we deploy in a way that causes minimum disturbance to the site visitors. In case something still breaks (broken code, missing database schema update), there should be easy way to rollback to previous version. Implementation details have not yet been decided. == Narrative == As a twn sysadmin I can update the site with minimum disruptions so that our translators get a better service. == Acceptance Criteria == * Merge conflicts can be resolved without breaking the site * Easy way to rollback to previous version * Handles local patches to core and extensions * Works with composer (as well it can given restrictions) * Can easily support HHVM's RepoAuthoritative mode if we choose to use it * Handles multiple wikis (production, development, sandbox)

//Migrated from: https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards/4590 // == Context == The current deployment system "wikiupdate" has served well, but it is showing its age. The addition of composer (among other things) have made it insufficient to meet our rising quality standards. The main issue is that on every upgrade of code, the site can break in multiple ways and stay broken until the deployer figures out what broke and fixes things. I am envisioning an incremental rewrite of the system. The architecture loosely mimics WMF's deployment system, although is much more simpler. It should be a two-phase system: update, then sync. In the first phase we will update our code, resolve any merge conflicts and other breakage. Then we deploy in a way that causes minimum disturbance to the site visitors. In case something still breaks (broken code, missing database schema update), there should be easy way to rollback to previous version. Implementation details have not yet been decided. == Narrative == As a twn sysadmin I can update the site with minimum disruptions so that our translators get a better service. == Acceptance Criteria == * Merge conflicts can be resolved without breaking the site * Easy way to rollback to previous version * Handles local patches to core and extensions * Works with composer (as well it can given restrictions) * Can easily support HHVM's RepoAuthoritative mode if we choose to use it * Handles multiple wikis (production, development, sandbox) == Deliverables == * //Enter link to actually done tangible deliverable(s)// **Open Tasks** {{ table query: SELECT Number, Name, Owner, 'Estimated effort (hrs)', 'Task Status' WHERE Type = Task and 'Schedule - Story' = THIS CARD and 'Task Status' < 'Done' ORDER BY 'Task Status', Owner, Name }} **Completed Tasks** {{ table query: SELECT Number, Name, Owner, 'Estimated effort (hrs)', 'Actual effort(hrs)', 'Task Status' WHERE Type = Task and 'Schedule - Story' = THIS CARD and 'Task Status' = 'Done' ORDER BY 'Task Status', Owner, Name }}