一次失败的项目经历

项目来源
去年10月底,师兄说有个老师要找他做项目,便带着我去了解需求。师兄跟老师聊了一个小时,大概懂了需求,我坐在一旁,跟不上他们的思路。回来工作室后,师兄给我写了下需求,随后,我便接下了。我找了一个前端的小伙伴,两个人一起做。
文档和价钱确定
老师把相关的文档、表格发给了我,我写了一份需求文档给老师看,她给领导看后,说文档写得不好。于是,我又改了。再发给她,再改,再发给她,再改。我就生气了,“我是个学生,只想踏实学习,不是来给你们主任写文档的”。后面价钱和需求文档继续扯着,而我的项目仍继续写着,直到11月中旬,文档最终确定,价钱1800元也最终确定。
技术变现喜悦
我对老师给的那些excel表进行了分析,然后设计数据库。遇到一些功能,老师如果自己手动去做的话要花两三天的时间,但我的网站帮她把数据给处理了,节省了她的时间。有一个功能是去爬取学校教务系统数据的,我写了个脚本,让老师可以每个学期都节省一个早上的时间重复性地查数据填数据了。我满怀激动,原来我用技术可以帮助别人解决这么多难题。
需求难度低估
之后,老师提出了一个排课的功能,这个功能是之前老师没提过的。老师把相关表格和排课流程告诉了我,我思考了许久,写了界面给老师看,老师看后,“你这样做反而增大了我的工作量了,我要的是自动排课”。自动排课,我不知道自己能否写出来,想了两三天,写了些代码,最后发现,逻辑太复杂了,不确定性太大,我告诉老师,这个功能实现不了。她开始怀疑我的能力了。
复杂功能完成
老师提出了自动安排考试的功能,这个在文档里有写,但我没想到,这么复杂。一个老师多个班级,一个班级多门课程,一门课程多个班级,还有其他的一些情况,自动安排考试的功能,我写了三天,后面又做了许多小的修改。所幸,最后老师对这个功能还是稍微满意。如果是她手动排考试的话,要两三天才能完成。
加需求
又有一次,老师提了个需求,叫毕业补考,这个是需求文档里没有写的。但我还是想说帮老师写了吧,研究了两天,我发现,这个要考虑的东西,以及对灵活性的要求太大了,用程序完成太难了。我跟老师说做不了,她不高兴。
拖项目
后来期末考,我跟老师说先不写了,她同意了。
再后来,寒假,我以前端的小伙伴不在身边为由,先拖着项目不写了,因为我感觉我做得太多了做得太长时间而后面不知道还要再做多久才能拿钱结束项目。
不愿放弃
2月中旬,快开学的时候,我想,我不能再拖了,便继续写项目,修改,给老师看,修改,给老师看,这样挣扎到3月中旬的时候,我感觉我尽力了,前端的小伙伴也改得烦了,不想再写了。我跟老师提出要拿钱,但她说网站还没做好,我已经不想再写。3月底,老师让我去找她,不给加钱,要写好再给钱,并且还要我改许多东西。我便决定,放弃了。
个人教训
1.需求文档要写清楚,最好能把网站的前端界面先做出来,给老师看下,分期收钱分期收钱分期收钱分期收钱
2.或许是第一个项目,所以一开始我对钱并不看重,加需求我也一味接受,但过了两个月,我的观念就转变了,“贱命一条,钱很重要”
3.加需求时必须考虑清楚,有时可以直接说不行
4.没有人有义务为我考虑,除了我少有的几个家人
5.靠自己,多思考,客户是技术白痴时,你要时时警惕,防止跟他一同傻逼
6.提升自己,多反思自己

<think>好的,用户让我帮忙写一份Jenkins的项目经历,而且要详细些。我需要先理解他的需求。看起来他可能在准备简历或者面试材料,需要展示自己在Jenkins方面的实际经验。首先,我得确定他可能需要的项目结构,通常项目经历会包括项目名称、时间、角色、技术栈、项目描述、职责与成果、具体实施细节、成果与价值、技术难点与解决方案这些部分。 用户希望详细,所以不能太笼统。可能需要具体的技术点,比如持续集成流程、自动化测试、部署策略、监控等。还要考虑他可能没有提到的方面,比如是否涉及多环境部署,或者与其他工具集成,比如Docker、Kubernetes、SonarQube等。这些都能增加项目经历的深度。 另外,用户可能没有明确说明项目规模和应用场景,但作为示例,我可以假设一个典型的微服务架构项目,这样能覆盖更多技术点。需要确保每个部分都有足够的细节,比如在持续集成流程中,如何触发构建,如何处理代码检查、单元测试、构建镜像等步骤。 还要考虑技术难点,比如构建效率问题,可能需要优化构建流程,引入并行构建或分布式构建。或者安全性方面,如何管理凭证,使用Vault等工具。这些内容能展示解决问题的能力。 可能需要分点来写,职责与成果部分用项目符号列出,让结构更清晰。技术栈部分要列出相关的工具和平台,显示技术广度。项目描述要简明扼要,说明项目的背景和目标。具体实施细节需要分阶段或模块,展示完整的CI/CD流水线设计。 还要注意使用行业术语,但避免过于晦涩,保持专业性同时易于理解。最后,成果与价值部分要有量化指标,比如部署时间减少多少,问题率下降多少,这样更有说服力。 总结下来,我需要构建一个结构合理、内容详实、技术细节丰富的Jenkins项目经历示例,覆盖设计、实施、优化各个方面,并突出实际成果和解决问题的能力。这样用户可以参考并根据自身经历调整内容。</think>以下是一份详细的Jenkins项目经历示例,您可以根据实际经验调整内容: --- ### **项目名称:基于Jenkins的持续集成与交付(CI/CD)系统搭建** **项目时间:** 2022.03 - 2023.06 **角色:** DevOps工程师 / 项目负责人 **技术栈:** Jenkins、Docker、Kubernetes、GitLab、SonarQube、Ansible、Prometheus/Grafana --- ### **项目背景** 公司原有部署流程依赖手动操作,存在环境不一致、部署效率低、错误率高的问题。项目目标是通过Jenkins实现自动化CI/CD流水线,支持微服务架构的快速迭代,覆盖代码提交、测试、构建、部署及监控全流程。 --- ### **职责与成果** 1. **CI/CD流程设计** - 设计多分支流水线(Jenkinsfile),支持开发、测试、生产环境独立部署。 - 实现代码提交后自动触发单元测试、代码质量扫描(SonarQube)、Docker镜像构建及推送到私有仓库(Harbor)。 - 集成Kubernetes实现滚动更新,部署到预发环境前自动执行API自动化测试(Postman+Newman)。 2. **工具链整合** - 通过Jenkins插件集成GitLab Webhook,实现代码提交后自动触发流水线。 - 集成JIRA实现构建结果与任务状态联动,构建失败时自动通知责任人。 - 配置Prometheus监控流水线执行耗时与成功率,通过Grafana可视化报表。 3. **安全与优化** - 使用Jenkins Credentials管理密钥,结合HashiCorp Vault实现敏感信息动态注入。 - 优化构建速度:通过缓存Maven依赖、并行执行测试任务,构建时间从15分钟缩短至6分钟。 - 设计灾备方案:Jenkins Master/Slave架构支持分布式构建,Slave节点按需动态扩容(基于AWS EC2)。 4. **团队协作** - 编写标准化流水线模板,降低开发团队接入CI/CD的学习成本。 - 为测试团队定制自动化验收测试流水线,集成Selenium实现UI自动化。 --- ### **具体实施细节** 1. **多阶段流水线设计** ```groovy pipeline { agent any stages { // 代码检查阶段 stage('Code Check') { steps { sh 'mvn clean compile' script { def sonarScan = tool name: 'SonarScanner' withSonarQubeEnv('sonar-server') { sh "${sonarScan}/bin/sonar-scanner" } } } } // 构建与推送镜像 stage('Build & Push Image') { steps { script { docker.build("myapp:${env.BUILD_ID}").push() } } } // 部署到K8s测试环境 stage('Deploy to Test') { steps { sh "kubectl apply -f k8s/deployment-test.yaml" // 触发自动化测试 build job: 'run-api-tests', wait: false } } } // 失败通知机制 post { failure { emailext body: "构建失败:${env.JOB_NAME} ${env.BUILD_NUMBER}", subject: "Jenkins构建告警", to: 'team@example.com' } } } ``` 2. **关键问题解决** - **构建环境差异**:通过Docker容器统一构建环境,避免"本地正常,线上失败"问题。 - **流水线可视化**:使用Blue Ocean插件提供直观的流水线状态视图。 - **资源争抢**:通过标签系统将不同项目分配到指定Slave节点(如Java项目使用高内存节点)。 --- ### **成果与价值** - 部署效率提升:单次发布耗时从2小时降至10分钟,部署频率从每月1次提升至每日多次。 - 错误率下降:生产环境问题减少70%,代码覆盖率从60%提升至85%。 - 扩展性增强:支持10+微服务项目同时运行,日均触发构建200+次。 --- ### **技术难点与创新** - **灰度发布实现**:结合Kubernetes的Ingress权重控制,通过Jenkins参数化构建实现流量逐步切换。 - **动态配置管理**:使用ConfigMap与Jenkins的Environment Injector插件实现环境差异化配置。 - **成本优化**:通过Spot实例运行Slave节点,基础设施成本降低40%。 --- 如果需要更贴近您实际经验的调整,可以提供具体技术场景或需求方向~
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值