Enterprise Holdings. The IT team of more than 2,000 people, introduced in 2018 speech how Enterprise Holdings is the DevOps transformation. We not only build a bear with a pipeline of CI / CD platform, call it SDLC. 200+ applications in the beginning, we pick out five as a pilot. The situation at that time proved to be successful DevOps Transformation Plan, our team of 4+ engineers and two architects, from a half years ago started development work across platforms, ensure that the platform can be adapted according to the needs of each business kind of cloud services, but also adapting existing middleware, we are constantly on the CI / CD platform improvements to suit all business scenarios. Its goal is to allow developers to focus more on specific project development, let the tool to solve some common issues. In order to reach the current results, we do a lot about the needs and problems of collecting feedback related to the operation of the platform work, so in the past year, we have this set of platform services to 70% of the applications, and this number is continued to increase.
In DevOps transformation process, our role is not a software developer, but we support the application development team and the application they are developing, our services between applications and infrastructure. In our point of view, application development should look like this:
- Developers locally
- Check the source code in the repository
- Build applications on a build server
- Run security scan
- Artifactory packaged and released to the JFrog
- l publish applications to different environments testing
- After all the testing, release into the production environment
This model is very simple, but very effective, but in order to achieve this process to do a lot of things, we have developed a number of templates called shared libraries, and this package and program, automated scripts, ansible scripts stored together version management to the source code repository, while providing to the application team to use. In order to support our applications team practice according to the above process, we use a lot of tools.
Continuous Integration tool chain include: git, maven, gradle, Artifactory, Bitbucket, BlackDuck, jenkins
Continuous delivery tools include: Ansible, jenkins, Bitbucket, Artifactory, Oracle, Tomcat and so on.
Simple tool to use, so someone will tell you DevOps is simple, but this statement is irresponsible, can not be considered the use of a tool, we practice the whole concept of DevOps. Our team consists of more than 2000 of it members, who developed a number of applications, we want to ensure that the entire team can work properly. Although different technology stack used by each team, using different platforms, but we need to find these people have in common, so that on our DevOps platforms to better fit all the teams and developers, and more than 200 applications. We need to ensure that everyone can use our platform, and real-time protection platform available, for which we use a lot of groovy development pipeline template above jenkins, automated script, jenkinsfile and so on for other teams to use. So that we can guide developers to use the tools of the time in accordance with the guidelines of our way to use, and in the process we set a lot of barriers, clearly tell the developers if these verify that their application is not normal is constructed. The result is that developers use our defined templates, automated security scanning, metadata is collected and uploaded to the application package Artifactory unified management. After our team can, through the results of these meta data collected, to the anti-found what your application includes. We maintain a json string in the template, the template will tell you what you do, what data to collect.
CI is to say the contents of the above, let's discuss the next CD. Unfortunately, so far we still have no way all of the CD process automation, we have too many scenes and platform development, there are a lot of complex work cut out for us to do. In our CD system ansible responsible for a lot of work, we use jenkins to manage our release process, and by ansible to perform publishing tasks, the most important thing is, we collected data (such as the release of the environment deployment, release time, test results, etc.), and these data as a metadata written back in Artifactory. In this process, you need to develop some custom automated test scripts, and apply them to the pipeline.
Our mission to build a run in the jenkins, jenkins test run in another task in such a way to ensure that our applications have a little bit of security.
During deployment of the biggest problems of our existence is that each deployment only to deploy an application, may involve a lot of applications at the same time release, we have to deal with this problem, make application operation and maintenance team to sort out the dependencies between applications relations, as well as the order of deployment. And maintains a list of the entire publication to be explained. Jenkins will be issued in accordance with these pre-defined list, and collected into question the process, which stage failure would not affect the other tasks and so on. These problems and sync to the pipeline and on the metadata of Artifactory. We gave all developers read-only access jenkins, so you can make sure that all developers can see these problems and to fix problems in a timely manner. Through this way, the first release reduced from four hours to one hour.
So then, we have to protect everyone is to perform in accordance with this standard on it.
Next we talk about some security topics
Safety is a very important part of our organization, there are many difficulties to implement. In our lack of safety awareness, we use the average user. These ordinary users, in fact, have permission to run these processes. Application teams are free to use and even vulnerable components, whenever we check into these problems, it is often these issues have been introduced to the test and production environments, we need to use a lot of open source software, but the introduction of these open source software needs to spend at least a month's time to assess whether it is security issues will affect our application, this process is agile development model that is not.
Each day there are a lot of loopholes are submitted to the public Internet, so we hope that our security concerns should not only be responsible for the security team, development, testing, operation and maintenance team, all engineers should pay attention to security, so we chose to scan into our CI / CD in the pipeline. We must force all applications in the pipeline to increase security scans, without this stage, then this line can not be passed. Although we do not want to accept the beginning, but after some time, developers find security team to find them fix vulnerabilities such things become less and less, we will gradually normalize the security scan this step. Such security team will also concentrate on spending time on the effects of application vulnerabilities, reducing the cost of communication with the development team test team. In addition, we developed a pipeline safety SLA, define a build of all depend on whether or not to meet the needs of the line. In this process is not entirely smooth, we found that each line in both security scanning spent so much time and resources, so we can improve the program, each scan only scans new dependencies, components, and new vulnerability signatures, which would also greatly improves the efficiency of the security scan.
Work, we will continue to maintain ongoing communication with the future of all of our support team, we want to keep abreast of all the ideas and product support team, combined with the actual situation, to show them how our CICD platform is to bring benefits to them ensure that the final each team can use our best practices, take the initiative to access our platform. In conclusion, you know the full CI CD should be such that it is not only to develop not only safety, but also operation and maintenance, testing. So basically the same as all pipeline. We really want to make sure that all of our design process is safe, this is our team everyone's goal, we really focus on fully integrated within the infrastructure team. Including integration server environment, network, technology stack, and so on, but in fact these are dependent on the integration of our CICD platform construction.
Please share more technical focus JFrog Jay Frog Online Classroom
1 Yue 14 Ri online classroom: "JFrog free Community Edition container warehouse JCR- Mirror Features and Practice"
Classroom benefits:
1. Learn JCR excellent features and powerful capabilities
2. By example shows, learn how to use JCR to better support the development of micro-services and applications and deployment Kubernetes
Registration link: https: //www.bagevent.com/event/6334008
Sweepstakes:
Five minutes before class ended, a raffle
First place: Small Love Speakers
Second: JFrog new version of Jay Frog T-shirt
Third: JFrog new version of Jay Frog T-shirt