前言
从企业架构咨询、行业顾问和项目经理的三个角色的融合个体，去分享对于DevOps不同的视角理解。（有点懒，懒得翻译之前自己写的东西了。）
What's in my mind - Software Application Process Engineering
A series of actions building up a process taking care of software application development, over a toolsets, guided by particular corporate culture, to ensure efficient delivery.
What’s in my mind - Delivery & Deliverables Quality
DevOps must ensure high-quality delivery, instead of just automation toolset & continuous integration & repeatable action for lower cost.
What’s in my mind - Corporate Culture of ‘DevOps’er, Especially for Production Line
Corporate culture helps on accumulating knowledge & experience as reusability, agile, productivity. Then feedback after individual delivery would be energy source of corporate culture.
In Nutshell
Make it clear: Something confusing while ‘DevOps’ing.
Confusion & Deviation of understanding between Dev Engineer and Customer, between Dev Engineer and Production Support Operator.
Whether it does matter after DevOps, for particular project.
DevOps is mandatory for any of projects, companies, and organizations, but cannot sacrifice a project to build a corporate platform which should be a separated NFR project.
Automation Test & Security of QA Perspective
Continuous Test is not that exciting while ‘DevOps’ing, but critical for high-quality delivery. Data-Preparation, Housekeeping, Agile-Sync, Script Quality are more tough than Scripting.
More Than Toolchain: Process Chain & Gateway
Step cannot be completed until meets acceptance criteria, and entire process should be supervised. When & What & How is harder than Whether while determining ‘Go’ or ‘NoGo’.
Relationship to agile & continuous delivery
DevOps wouldn’t be implemented & pushed forward well, just due to ‘Agile’ing project & customer expectation improperly, so that ‘Automatized’ has to be reworked.
Transformation from Legacy to Young-Bird & Workload Automation
Development process related to operations of system would dramatically show the value of DevOps, then improve productivity.
Enterprise-Level DevOps
Demands & Pain-Points
A automation pipeline must be built-up over approved toolset to follow strictly corporate procedure & minimize impact of any of changes, with reasonable efforts & acceptable balancing.
Organization & Team – Overview
TGB is actual ‘heart’ of project body, Release Manager is combined role during Ops of Dev, working closely with TGB & QA, after that Operation Manager takes over Ops.
Organization & Team – Technical Governance Board (TGB)
TGB is fully responsible for actual execution and governance of delivery quality, composed of technical solution architecture mainly being aware of managerial and processing engineer.
Organization & Team – Industry Software and Services (ISS)
Actually more strict review, aka Governance, is mandatory during entire delivery processes, also in Corporate Level with Customer directly.
Organization & Team – Release Management / Coordinator (RM)
RM is temporary role responsible for particular timeframe to coordinate entire deployment actions, even DevOps is ready, since reality is more complicated, actually incident is always there.
Organization & Team – Configuration Management (CM)
CM is acting as one of gateway, more than the guy taking care of deployment only, setting up environment, assign account, control SCM.
Organization & Team – Operation Manager (OM)
OM in Operations Stage would be transformation role of RM during Operations of Dev stage, who coordinating post-dev actions, processes, resources, especially for App over PaaS & IaaS.
Collaboration – Overview
It is collaboration from multiple organizations, not limited to Dev teams & Dev Stages. But each part should only run where it is expertized, and operations after Go-Live is more critical.
Collaboration – Pipeline & Gateway
Operations in Dev needs to support corresponding automation actions after merge between 2/3 branches, then rollback action would be quite necessary and being invoked frequently.
Collaboration – Work Product Review (WPR)
WPR focus on 'Defect Removal' & 'Gateway' deliverables, to ensure work product meets its specified requirements, identify any defects, action items or issues, also collect rework effort.
Collaboration – Request for Change (RFC)
Changes, no matter routine task or hotfix, to be published to upper environment, need to be supervised, so that quality could be ensured, risk could be traced, placeholder takes responsibility.
Practice – POM Hierarchy
Micro-Modulization & Parentification to improve capability of orchestration & standardize delivery, as well as governance direct reference of external sources.
Practice – Developer Workflow
Branching according to task & WPR result, individual only works on personal branch after merge from master branch. ‘Connector’s are leveraged to sync between ALM & Rally & Git.
Practice – Release & Promotion Strategy
In reality, release is more than binary, well-organized documents & handbook and so on are also required by customer as part of final deliverables. But anything must be supervised by RM.
Practice – Artifact Management & Delivery Strategy
Artifact more than source code is always mandatory for client-facing delivery, FR, TD, TC, Handbook … management & delivery is still lack of support from DevOps concept.
Practice – Routine Toolsets involved during Operations of Dev Stage
What is being leveraged is not individual willpower, all bases on SOW, Partnership, Project, Resource, Stage and so on. Therefore DevOps is customized process engineering.
Practice – Standardized Development Platform (SDP)
Standardize everything during Dev to avoid any incompliance & secure delivery, then care shared resources, finally have entire deployment agile with minimized impact.
Practice – Responsibility of Monitoring Platform
Acknowledge issue & identify cause via operation of Dev, being routine weapon during operation support.
Practice – Advanced Transportation Coverage (ATC)
ATC is team of operations who takes care of Biz-Irrelevance operations, and more similar like RM during operations of Dev, but its primary responsibility is to handling incident.
Practice – ES On-Call Notification (EON)
EON was based on Centralized Logging & Interception mechanism, normally enabled after MO release. Therefore operations need to take care of it during deployment & hotfix.
Practice – Branching Strategy
Branch per customer & project, then release, but finally merge into Main Branch for building up Production Line, and Future Branching Model.
Practice – Building Strategy
Configure different building strategy & build up DevOps deliverables, based on usage. But promote to upper level should be associated with more strict criteria & governance control.
Practice – Source Code Isolation & Configuration Centralization
Isolate source code from configuration, then build up a configuration repository and use Env. placeholder within source code, but source code must know exactly what Env. is.
Practice – On-The-Fly & Parallel Business Cutover
Sometimes it is really hard to drive operations of dev, while legacy system is still running, but part of them is being retried.
Practice – Job Scheduling & Orchestration via Workload Automation
Summary
KISS (Keep it Simple and Stupid): Be the master of tool while never be the slave of tool, and let customer know we are experienced & qualified.