CODING announced CODING 2.0 at Kubecon 2019 two days ago. Behind this is CODING’s thinking on R&D management and team building. Since CODING was founded, we have been exploring ways to “make development easier”. By breaking down the big vision of “making development easier” into quantifiable product goals, the hope is to reduce rework in the development process and improve the speed and quality of software delivery in the form of tools.
The beginning of cloud development
At the beginning of CODING, the blueprint in my mind was that developers would discuss requirements, assign tasks, write code, modify code, demonstrate code, and complete relevant tasks, and the whole development operation would be done here.
So the product structure was: Lightweight task management – discussion – code version management – demonstration platform Under this system of product, the product manager will assign a task to the designer, designer completion of design, product manager, acceptance and then assign a task to research and development personnel, research and development personnel to push code, can do presentation in the demonstration platform for acceptance of product manager. This work model is very suitable for small teams with simple process and quick response. CODING teams also use it, and it supports the development pace of rapid start, quick launch and quick response to feedback in the early stage of CODING products.
Practical problems encountered in the growth process of the enterprise
Soon, with the development of CODING business, there were more and more CODING product lines and more and more teams. When the team reached 100 people (60% of whom were r&d), we found that the team began to become “unmanageable”. The quality of the final launch depends very much on the management ability of the department Leader and self-cultivation of the developer. We put a lot of processes and specifications in place to make sure the product lived up to expectations, but that slowed us down. At one time, we were very worried that the advantage of a start-up company lies in its high efficiency and rapid product iteration, but if we lose this advantage in the process of development, we will be easily surpassed by others.
Fortunately, we are not the first to encounter this problem. There’s a famous idea in the Myth of the Man-month:
Adding manpower to a late software project makes it later. — Fred Brooks, (1975)
“If you try to solve the software schedule problem by adding more people, you will only make it slower.” Because:
Communication cost = n(n-1)/2 n= number of team members
For example, a team of 10 people will have 45 communication channels, which will increase to 1,225 when it reaches 50 people. As the number of people increases, the cost of communication within a team increases exponentially. Understanding the cause of the problem leads to the solution: “We need more and smaller teams” — reducing communication costs by splitting the team into several smaller teams with internal closed loops. So we have a slightly more agile organizational structure:
This way of working is agile and not thorough. The problem lies in operation and maintenance. Considering the online stability and the coupling degree of the system, operation and maintenance cannot be separated into each team. Although each product line has independent product managers, designers and developers, operation and maintenance need to assist in launching the test environment, and then testing and staging can be carried out in two environments. A great deal of time is wasted by useless waiting.
At the same time, due to the different work objectives, the contradiction between development and operation and maintenance is increasingly deepened, and each feels that the basic work of the other is not completed. The team is in trouble.
We need DevOps
In the midst of adversity lies opportunity, which we found in our conversations with users is a common affliction of most teams: how can ** teams be organized to maximize software output? The natural goals of each character are different, making it difficult to get a quick and good launch.
The idea behind DevOps is to break down this barrier, to integrate Development and Operations, and to align teams with business needs. DevOps not only completes part of the operation and maintenance work through tool-assisted development, but also is an idea and methodology of software R&D management. What DevOps pursues is an ideal state of R&D collaboration without barriers.
The first task of practicing DevOps is to reach a consensus on the goals and ethos of DevOps and guide the effort accordingly. As a result, we have set a clear timetable for the gradual separation of microservices from the new product line and the optimization of the whitelist acceptance mechanism. In the long run, it is hoped that development will be less dependent on operations while ensuring better software quality.
After that, the team tried to scale up the performance improvements that the tool would bring. Although many tools have been used before, such as Jenkins to build continuous integration locally, self-built Docker Registry for build management, and Excel for test management, etc. However, it is relatively scattered and has high training costs. At the same time, manpower is needed for selection, construction and maintenance. Even if it is only half development and half operation and maintenance, it is also a small investment of several hundred thousand a year.
We desperately need a set of tools that are ready to use to help us improve the productivity of our r&d team, rather than spending manpower and time on infrastructure construction. However, there is no such product on the market, and our users have similar problems. They can only build with several open source products.
Why not develop such a system so that DevOps transformation enterprises with the same difficulties can quickly complete the tool construction? Making Development Easier is CODING’s mission and vision, which urges the CODING team to provide better tools and services for developers. In addition, CODING’s core business, code hosting, is the foundation and fulcrum of DevOps tools. As a result, CODING has adjusted its product goal to provide a complete set of R&D management tools for enterprises since the beginning of 2018. After more than a year of efforts, CODING has now fully opened its continuous integration capabilities and workrepositories to SaaS versions of its services, supporting all major languages and multiple target environments.
DevOps development tool chain: Code as application
We believe that in the near future, with the maturity of tools, we will enter the era of “Code as a Product”, where developers do not need to do complicated other work, only need to write the Code, the application will run automatically, so that enterprises reduce operation and maintenance costs, improve the efficiency of software development department.
The code as Application tool requirements are divided into three phases:
- Continuous integration phase: Use the continuous integration tool to run the configured commands to avoid repeated efforts.
- Automated deployment phase: The build creation process itself becomes easy to create application distribution without learning additional operations development knowledge.
- Serverless stage: Truly release without awareness, the code is written and released.
The introduction of continuous integration and artifact library in CODING 2.0 marks the beginning of continuous integration of CODING. Users only need to push code or merge request, and then they can start continuous integration for construction, unit test, security scan, etc., and generate artifacts and store them in the artifacts library. Improve the quality and speed of software delivery while reducing the uncertainty caused by the introduction of “people” into the build process.
In addition to tools, CODING also provides enterprises with additional services such as coaching and training for the implementation of r&d processes and agile training. At present, dozens of enterprises have applied CODING DevOps tools to internal production, greatly improving the efficiency of team DevOps transformation.
There’s something else I want to say
China’s software industry has a short development time, a fast development speed, a short talent pool and an awkward position. Even for Internet companies that started with software services, with the growth of the company, the status of the business department is gradually higher than that of the software R&D department. Except in a few areas, the drive of Chinese companies’ R&D departments has often been drained away in the process. In addition, the labor cost of the software industry keeps increasing. As a support and cost department, managers tend to regard the software R&D department as a cost department, with the idea of “whether the cost can be reduced”.
However, nowadays, the rapidly changing market environment poses a high challenge to the software r&d department, which is difficult but also an opportunity. An efficient R & D team can not only reduce the friction and waste between systems, so that the R & D department can quickly respond to market demand, but also can continue to deliver high-standard products, so that product verification into a positive cycle, leading the value realization of the whole team.
But building such a team requires far more than tools. It requires the experience, knowledge, and determination of the team leader to change. Many pioneering teams took the lead in reform, and while CODING helped them transform, it also saw the productivity of their teams after the difficulties, trade-offs, and progress they encountered due to reform.
We hope to see more Chinese software companies understand the Spirit of DevOps and apply it to their own team management to deliver first-class software products to China and the world. It’s hard, but it’s really worth it.
Click on CODING 2.0 to experience agile DevOps toolchain development
