[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-gray-release-for-smb-en":3,"blog-related-gray-release-for-smb-en":29,"blog-adjacent-gray-release-for-smb-en":63},{"id":4,"slug":5,"title":6,"excerpt":7,"content":8,"cover":9,"tone":10,"author":11,"publishedAt":12,"updatedAt":12,"readingMinutes":13,"featured":14,"tags":15,"category":19,"seoSettings":28},36,"gray-release-for-smb","Gray Releases for Small and Mid-Sized Projects","Without heavy infrastructure, simple techniques still keep release risk under control.","\u003Cp>Gray releases sound like something only large companies do. In practice, once you have more than a hundred users it is worth planning. Most of our clients run internal systems with a few hundred users, and this approach works for them.\u003C\u002Fp>\n\u003Ch2>Three levels of gradual rollout\u003C\u002Fh2>\n\u003Cp>By account: two or three departments get the new version first while others stay on the old one, limiting the blast radius.\u003C\u002Fp>\n\u003Cp>By feature flag: new features ship disabled and open to selected users through configuration. If something breaks, turn the flag off instead of rolling back code.\u003C\u002Fp>\n\u003Cp>By time window: release during off-peak hours and notify key users, never during month-end closing.\u003C\u002Fp>\n\u003Ch2>Two things that come with it\u003C\u002Fh2>\n\u003Cp>A release checklist covering database changes, configuration and dependency versions. If one item is missing, do not release.\u003C\u002Fp>\n\u003Cp>A rollback plan that names who executes it, how long it takes and whether data can be reversed. Shipping without a rollback plan is gambling.\u003C\u002Fp>\n\u003Cp>A gray release is not technical showing off; it is basic respect for the client's business. Half an hour of preparation saves a night of debugging.\u003C\u002Fp>","","cyan","佳益方圆团队","2026-08-06T15:18:00+08:00",1,false,[16,17,18],"Releases","Operations","Risk",{"id":13,"parentId":20,"slug":21,"name":22,"description":23,"icon":24,"cover":9,"tone":25,"kind":26,"sortOrder":27,"count":20},0,"engineering","Engineering","Hands-on engineering practices in architecture, performance optimization, AI integration and cross-platform delivery from our R and D team.","cpu","blue","article",60,{},[30,40,52],{"id":31,"slug":32,"title":33,"excerpt":34,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":35,"updatedAt":35,"readingMinutes":13,"featured":14,"tags":36,"category":39},30,"integration-api-pitfalls","Five Traps in Enterprise System Integration","However complete the API documentation is, integration usually stalls on field semantics, timeouts and repeated pushes.","2026-10-17T09:00:00+08:00",[37,38,22],"Integration","APIs",{"id":13,"parentId":20,"slug":21,"name":22,"description":23,"icon":24,"cover":9,"tone":25,"kind":26,"sortOrder":27,"count":20},{"id":13,"slug":41,"title":42,"excerpt":43,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":44,"updatedAt":45,"readingMinutes":46,"featured":47,"tags":48,"category":51},"why-enterprise-systems-age","Why Enterprise Systems Start to Age After Three Years","A system can pass acceptance with every feature checked, then feel awkward three years later. The problem is rarely the code — it is the changes that were never considered at delivery.","2026-10-16T09:30:00+08:00","2026-10-18T15:58:14.648+08:00",2,true,[49,50],"System Evolution","Architecture",{"id":13,"parentId":20,"slug":21,"name":22,"description":23,"icon":24,"cover":9,"tone":25,"kind":26,"sortOrder":27,"count":20},{"id":53,"slug":54,"title":55,"excerpt":56,"content":9,"cover":9,"tone":25,"author":11,"publishedAt":57,"updatedAt":57,"readingMinutes":13,"featured":14,"tags":58,"category":62},31,"idempotent-design-basics","Idempotency: Duplicate Submissions Are Not Just Double Clicks","Retries, redelivery and impatient users all send the same request more than once. Idempotency belongs in the API design.","2026-10-05T10:13:00+08:00",[59,60,61],"API Design","Idempotency","Reliability",{"id":13,"parentId":20,"slug":21,"name":22,"description":23,"icon":24,"cover":9,"tone":25,"kind":26,"sortOrder":27,"count":20},{"previous":64,"next":81},{"id":65,"slug":66,"title":67,"excerpt":68,"content":9,"cover":9,"tone":25,"author":11,"publishedAt":69,"updatedAt":69,"readingMinutes":13,"featured":14,"tags":70,"category":74},15,"retro-of-a-failed-project","A Full Post-Mortem of a Project We Should Not Have Taken","Vague requirements, seven decision makers and a budget nowhere near the expectation. The project failed in slow motion.","2026-08-08T14:05:00+08:00",[71,72,73],"Startup","Failure","Retrospective",{"id":75,"parentId":20,"slug":76,"name":77,"description":78,"icon":79,"cover":9,"tone":25,"kind":26,"sortOrder":80,"count":20},6,"founder-notes","Founder Notes","Reflections from the founding team on business, management and product, documenting the growth of a software company.","pen-tool",10,{"id":82,"slug":83,"title":84,"excerpt":85,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":86,"updatedAt":86,"readingMinutes":13,"featured":14,"tags":87,"category":91},56,"form-design-tradeoffs","Form Design: One Field Fewer, One Step More Completion","Every field has a cost. Designing a form means deciding which information is truly needed now.","2026-08-04T15:18:00+08:00",[88,89,90],"Forms","Product Design","B2B",{"id":46,"parentId":20,"slug":92,"name":93,"description":94,"icon":95,"cover":9,"tone":25,"kind":26,"sortOrder":96,"count":20},"product-thinking","Product Thinking","Requirement analysis, user experience and product design methods, plus the thinking from business problems to product solutions.","lightbulb",50]