开发基于 Laravel 项目自动化部署的扩展包之 laravel-unideploy
在实际项目开发过程中, 针对 PHP 项目的自动化部署, 市面上较为成熟和可靠的解决方案稀缺。目前, 国内 PHP 项目的部署方案相对缺乏, 我采用的是 21云盒子
关于部署Laravel项目的实践方案属于初级阶段，在实际操作中需要完成一系列基础工作。具体来说就是使用composer进行全局安装在本地环境内完成第一步工作；随后根据自身项目需求开发符合自身需求的功能模块并进行详细设置；同时还需要对服务器进行全面配置包括但不限于主机设置以及共享目录管理；最后为了保障系统的安全稳定运行建议采用sudo免密码账户来进行服务器配置等多方面工作
- 刚开始可能遇到的问题比较低级，但是通过翻看 deployer 的各种 issues，逐步的把问题解决，也算是有一点小进步吧。
- 关于使用 deployer 部署 php 项目，我后来在 Laravel-china 社区看到了 Overtrue 的一篇文章，总结的很好，方便以后查阅，再此我记一下链接，文中把整个部署过程讲的很通透，下面的评论也有一些可能会在未来遇到的问题，总体来说很赞👍👍
- 关于使用 deployer 部署 Laravel 项目，虽然此 package 已经提前预设了 laravel recipe，包括共享目录
storage，共享文件.env，集成各种artisan等等，但是我们也在试想如何更优雅与 Laravel 贴近，于是想在此基础上封装一个扩展包，起初在此扩展包我们想添加的功能是：添加部署群消息提醒，添加修订日志，自动上传新的 .env 文件等，搜索博大的 github 仓库，果不其然发现了一个package集成 deployer，于是在此基础上我们重新整合了需求，定制自己项目的自动化部署扩展包 laravel-unideploy，目前还在不断完善中，但是大部分代码都是基于 laravel-deployer - 选用 Yml 配置加载自定义配置，配置更加轻便灵活
- 更优雅的记录每次修订日志，回滚日志
- 衔接web hook通知，后续也会继续完善，目前暂时只用于公司内部系统通知。
原来一开口就抱怨别人程序包得不好看多（感慨），咖啡的时间内沉淀下来后有了独特的见解——在一百个 php 程序员眼中总有一千种代码实现方式而如何在这两者间找到平衡点始终是一个耐人寻味的话题（感悟） 😇
总结一下实际项目开发中遇到的一些问题
问题一
acl 未安装，下面如下 shell 返回空
if hash setfacl 2>/dev/null; then echo 'true'; fi解决方案
sudo apt-get install acl参照GitHub Issues平台中的相关问题链接issues，无法正确设置可写目录的正确权限。
问题二
reload php-fpm 没有权限
sudo need to enter a password解决方案
sudo vi /etc/sudoers
your_user_name ALL=(ALL) NOPASSWD: ALL需要注意的关键点在于：将部署账号的sudo权限设置放置在文件的末尾位置，并且在操作完成后进行验证。建议将sudo权限设置放置在文件的末尾位置，并且在操作完成后进行验证
需要特别注意的地方是 将部署账号的 sudo 配置在文件的最后一行, 避免有 覆盖 的情况, 可以配置完执行 sudo cat /etc/sudoers 看看是否有权限
问题三
git deploy failed
Fetching origin
ERROR: Repository not found.
fatal: Could not read from remote repository.解决方案
eval `ssh-agent -s` &&
ssh-add ~/.ssh/id_rsa在项目部署的主机配置中启用forwardAgent功能，并在本地添加自己的公钥以确保在部署过程中能够与服务器维持会话连接。
其他尚未完全实现的配置仍在逐步实践的过程中，在这一过程中会不断遇到各种问题，并及时记录相关情况。每日反省自己的言行举止。
记了这么些简短的笔记。快到午夜十二点了。意外地发现键盘表面因为频繁使用 command + c而开始出现磨损。这么多天过去了。未来漫长岁月里。风雪是你。平淡是你。清贫是你。荣华也是你。
无二之旅 是一个专注于打造有温度的旅行体验的平台，在这个平台上, 今年的重点目标之一在于打造属于自己的 uni-package 。在实践中往往被视为个人成长最有效的途径, 因此, 本次旅行活动将重点关注实践环节, 以实现个人价值最大化