希望踩过的坑能为您铺平前进的路
UPDN .CN

一句话诠释devops

管理员阅读(8)

今天看到一句话,感觉不错,记录下来

DevOps是文化,组织,工具于一体的实践,devops框架一般可能就是一体化管理平台,或者是全流程监控平台

gitlab日志在哪里

管理员阅读(18)

gitlab会将所有的操作记录成日志,方便进行分析,gitlab的日志系统分为以下几类:

1、production.log:该日志位于/home/gitlab/logs/gitlab-rails中,其作用是记录gitlab的每次请求的具体信息,包括请求的URL、ip地址、请求类型、以及此次请求所涉及的具体代码、SQL请求以及SQL请求消耗的时间。比如:

2、application.log:此日志文件位于/home/gitlab/logs/gitlab-rails中,其作用是记录创建用户、创建项目、移动项目等日志。

3、githost.log:此日志文件位于/home/gitlab/logs/gitlab-rails中,此日志的作用是记录对gitlab服务器的错误请求日志。

4、sidekiq.log:此日志文件位于/home/gitlab/logs/gitlab-rails中,gitlab中可能存在一些任务需要运行很长时间,因此会选择将这些任务在后台执行,sidekiq.log文件就是用来记录这一类任务的处理信息,此日志文件是一个软连接文件。

5、gitlab-shell.log:此日志文件位于/home/gitlab/logs/gitlab-shell中,该日志文件的作用是记录执行gitlab命令以及为项目添加ssh权限的日志文件

6、unicorn_stderr.log:此日志文件位于/home/gitlab/logs/unicorn,该日志文件的作用是记录gitlab的web服务器的相关记录。

7、repochec.log:此日志文件位于/home/gitlab/logs/prometheus

基于k8s+docker的企业级jenkins可伸缩集群的搭建

管理员阅读(51)

背景:

大公司需要进行编译的工程或者对象非常庞大,因此需要大量的物理节点作为slave,而且这些环节相对固定,可能很难适应多种类型项目的编译测试,一旦salve节点遭到破坏,进行修复甚至重建非常麻烦。

企业级

我们是否一定要做统一的Jenkins Master,是否一定要大而全,再解决单点瓶颈问题,是否可以把Jenkins Master根据团队级去做拆分,或者按照环境拆分,包括测试阶段、个人阶段,和线上生产发布阶段。

docker部署:

使用docker可以解决服务配置复杂,重建服务困难的问题,大体架构如下

master高可用

作为master,把Jenkins Master放到了容器平台上,虽然没有实现完美的高可用,完美动态的扩容,但是可以实现的就是HA,当Jenkins挂掉的时候可以用同样的方式快速恢复。

mac上visual studio code集成github

管理员阅读(54)

实现编写完代码可以提交到github上

1.首先确认你的mac上已经安装了git,可以通过git -version,如果提示你需要安装xcode那就安装

2.终端找到存放代码的目录,执行git clone https://github.com/909012142/tingyuncheck.git

3.vscode command+o 打开对应的目录

4.编辑代码,保存

5.然后切换到git目录,点击加号,加到版本控制,然后点击对号,提交到本地分支。点击push提交到github,第一次输入用户名密码。

微软IDE工具Visual Studio Code

管理员阅读(38)

Visual Studio Code 击败 Xcode

推荐 windows mac 使用

官网:https://code.visualstudio.com/

汉化:
1.扩展》搜索关键词chinese》install
2.命令面板》配置现实语言》修改locale.json》en改为zh-cn

使用:(python举例)
扩展里边安装python

如何理解持续集成、持续交付、持续部署?

管理员阅读(1073)

CI, CD AND CD

CI很容易理解,就是持续集成。但是CD既可以指代码持续交付,也可理解为代码持续部署。CI和CD之间有很多相似的部分,但是也有很大的区别。

持续集成(CONTINUOUS INTEGRATION)

持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。

在持续集成环境中,开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前,都需要通过编译和自动化测试流进行验证。这样做是基于之前持续集成过程中很重视自动化测试验证结果,以保障所有的提交在合并主线之后的质量问题,对可能出现的一些问题进行预警。

持续交付(CONTINUOUS DELIVERY)

持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试,我们还需要有自动化的发布流,以及通过一个按键就可以随时随地实现应用的部署上线。

持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。

通过持续交付,您可以决定每天,每周,每两周发布一次,这完全可以根据自己的业务进行设置。

但是,如果您真的希望体验持续交付的优势,就需要先进行小批量发布,尽快部署到生产线,以便在出现问题时方便进行故障排除。

持续部署(CONTINUOUS DEPLOYMENT)

如果我们想更加深入一步的话,就是持续部署了。通过这个方式,任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预(没有一键部署按钮),只有当一个修改在工作流中构建失败才能阻止它部署到产品线。

持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工,而持续集成、持续交付、持续部署恰恰可以早发现早解决,从而可以避免这个问题。

持续部署是一个很优秀的方式,可以加速与客户的反馈循环,但是会给团队带来压力,因为不再有“发布日”了。开发人员可以专注于构建软件,他们看到他们的修改在他们完成工作后几分钟就上线了。基本上,当开发人员在主分支中合并一个提交时,这个分支将被构建、测试,如果一切顺利,则部署到生产环境中。

 

 

到底值不值这样做呢?

持续集成:

你需要具备哪些条件:

你的团队需要为每个新功能,代码改进,或者问题修复创建自动化测试用例。

你需要一个持续集成服务器,它可以监控代码提交情况,对每个新的提交进行自动化测试。

研发团队需要尽可能快的提交代码,至少每天一次提交。

你能获得什么呢?

通过自动化测试可以提早拿到回归测试的结果,避免将一些问题提交到交付生产中

发布编译将会更加容易,因为合并之初已经将所有问题都规避了

减少工作问题切换,研发可以很快获得构建失败的消息,在开始下一个任务之前就可以很快解决。

测试成本大幅降低-你的CI服务器可以在几秒钟之内运行上百条测试。

你的QA团队花费在测试上面的时间会大幅缩短,将会更加侧重于质量文化的提升上面。

持续交付

需要具备什么条件?

你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求

部署需要自动化。触发是手动的,但是部署一旦开始,就不能人为干预。

你的团队可能需要接受特性开关,没有完成的功能模块不会影响到线上产品。

你能收获什么?

繁琐的部署工作没有了。你的团队不在需要花费几天的时间去准备一个发布。

你可以更快的进行交付,这样就加快了与客户之间的反馈环。

轻松应对小变更,加速迭代

持续部署

需要具备的条件:

研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。

你的文档和部署频率要保持一致。

特征标志成为发布重大变化过程的固有部分,以确保您可以与其他部门(支持,市场营销,公关…)协调。

可以获得什么?

发布频率更快,因为你不需要停下来等待发布。每一处提交都会自动触发发布流。

在小批量发布的时候,风险降低了,发现问题也可以很轻松的修复。

客户每天都可以看到我们的持续改进和提升,而不是每个月或者每季度,或者每年。

如前所述,您可以采用持续集成,持续交付和持续部署。你怎么做取决于你的需求和你的业务情况。如果你刚刚开始一个项目,并且还没有客户,那么你就可以去创建这些工作流,最好是将这三个方面都实现,并且在你的项目迭代和需求增长中同时迭代它们。如果您已经有一个生产项目,那么您可以一步一步地分阶段去实现他们

UPDN

关于我们联系我们