一千个项目可能有一千种 Git 分支管理策略。
—— 严士比亚·北
在不同的公司、项目里跌打滚爬过,你是否每次总在适应团队各种各样的 Git 操作规范?作为测试,若你的工作与持续集成有关,又是否因为不同的 Git 规范而头痛?
即使是本文介绍的分支管理策略,也不一定适合大家的项目,但我们长期使用下来,经过多次优化升级,一定不会难用。
Aims at Test Architect
一千个项目可能有一千种 Git 分支管理策略。
—— 严士比亚·北
在不同的公司、项目里跌打滚爬过,你是否每次总在适应团队各种各样的 Git 操作规范?作为测试,若你的工作与持续集成有关,又是否因为不同的 Git 规范而头痛?
即使是本文介绍的分支管理策略,也不一定适合大家的项目,但我们长期使用下来,经过多次优化升级,一定不会难用。
根据我之前的几篇「Django 系列」文章,后端架构中我使用了 Django + Celery + RabbitMQ 三个框架/服务。现在有几个问题:
在我以往的实践中,容器的编排使用了 docker-compose
实现,问题一就已经解决。但 docker-compose
也只是用于编排,可以各启动三个服务的一个容器,性能与高可用性就可能不能满足要求。
对于性能与高可用,如果是大型项目,目前不二的选择就是 Kubernetes(K8s)
,但是我的项目不足以称之为「大型项目」,因此我考虑的是,如何在单宿主机上提高性能与高可用。