In another application DevOps Agile software development team

　　In another application DevOps Agile software development team. So by contrast, which is superior?
　　
　　One side, there are industry-proven scrum master, who its friends Extreme Programming, and derived therefrom LeSS, SAFe, DAD, is agile.
　　
　　On the other side, there are lean culture machine, use the code continuous delivery of its infrastructure, its name is the development of the left, the right is the operation and maintenance together is DevOps.
　　
　　Although I did the best I could in the popularity of these two concepts, but people debate about Agile and DevOps still make them sound completely different. Worse, even though they already have their own jargon and slogans, but the two concepts is no way to accurately define. Given born earlier than DevOps agility, so it's relatively clearer definitions, but the definition of a wide variety of DevOps is still a lot of people are confused. It is precisely because of both a lack of precise definition, so people often have led to some misunderstanding.
　　
　　Many people think agile equal scrum, DevOps equal continuous delivery. Oversimplified understanding between Agile and DevOps allow the formation of unnecessary confrontation, but eventually you will be surprised to find that in fact the two are very good friends!
　　
　　There is no doubt the link between DevOps and agile for a long time. In 2008 Agile conference, Patrick DuBois and Andrew Clay Schafer tries to establish a relationship between the two and that "agile architecture" concept, then, the relationship between the Agile and DevOps had emerged. Although Patrick was later proposed the term "DevOps", but still agile Assembly was traced to a starting point of DevOps. So we might as well surface through Scrum and continuous delivery of in-depth understanding of the history between the two, and think about what correlation there is between Agile and DevOps.
　　
　　First, more than just agile Scrum
　　
　　Some teams, scrum so that the team work between rigid, struggling and mass production, between high returns. There are some teams, scrum instead of subjective and objective with excessive commitment and focus. We can also see it as a dogma. When the business limit or received work itself needs to make a change, the team will use the basic principles of agile scrum, and look at their work and make more efficient adjustments. Especially when applied to business outside of the scrum software development environment, which is particularly important.
　　
　　Planning ahead unplanned work
　　
　　in DevOps community, there are experienced people feel agile scrum can effectively track the work plan. Some of the running work can be planned: a major system changes such as publishing, data switching centers or system upgrade. But in the run most things is no way to plan: to reach peak performance, such as, system outages or security issues. These incidents need to react quickly. No time to wait until these matters before making or determining the priority placed next sprint planning meeting in processing the backlog. For this reason, many teams began to slowly accept the idea of DevOps, and then introducing Kanban than Scrum. This allows teams to simultaneously track two types of work, to help them understand the link between the two. Or they take a comprehensive approach, called Scrumban or Kanplan (that is, there is backlog Kanban).
　　
　　In large part, scrum key may be widely used method is that it is not technology restrictions. Scrum as a lightweight management approach, often bring great changes to the team. Before, there may be a matter of priority from multiple master competition with each other, but in the scrum, backlog only in the presence of a set of priorities. Previously, the team there may be cases while promoting a lot of work, and now replaced by a program of work that can be completed within the time limit. Taken together, these can be the team's productivity to a new level. However, the team may be due to the lack of technical practice is limited, such as code review, automated acceptance testing, continuous integration.
　　
　　Other agile methods such as Extreme Programming, but also how to make the technical team to maintain sustainable delivery of rhythm to management and stakeholders to provide transparency and visibility put forward specific demands. Some Scrum teams tend to research and development tasks in the backlog. Although this coping well under the guidance of the scrum, but soon encountered Product Owner biased questions about product features. Unless the technical capacity Product Owner is very strong, otherwise TA may be unable to assess the costs or benefits of technology. Especially when extended to the technical aspects of operation and maintenance tasks, support for reliability, performance, security, etc., it is more difficult for the Product Owner.
　　
　　Product Owner and Service Owner
　　
　　at Worktile, we recognize that our products and operations set two different roles necessary. Product Owner good at understanding the functional needs of the user, but may not be good trade-off between priority and non-functional product features functional performance, reliability and security. Therefore, some SaaS products are also equipped with a Service Owner role, responsible for determining the function of the aforementioned non-functional priority. Although the two roles often need to bargain, but in most cases, independent teams can complete their own tasks in both roles. Although this is not the only way to "strengthen feedback", but it can be overcome Product Owner for product features more common prejudice. But the only way to set up 'two Owner' DevOps is not achieved. It is important to understand the non-functional features as "functional", and they like the functionality of user stories, like planning and prioritizing.
　　
　　DevOps before becoming mainstream, can not determine the result of the natural development of certain scrum is DevOps.
　　
　　Agile methods, Scrum is an inherent "process improvement" mechanism, called a review meeting. Therefore, we have reason to believe that some of the scrum team will want to use DevOps as a source of inspiration, with scrum review meeting as an opportunity to adjust the direction of DevOps. However, the fact that we realized that most teams need to inject external ideas. DevOps before becoming mainstream (even if the school will learn to be content) results, we can not determine the scrum must be a natural development of DevOps. Team in the end there is a DevOps agility coach or coaches involved is not important, as long as he can give the team bring experience in building automation, testing, deployment, etc.
　　
　　Two, DevOps is also not limited to the continuous delivery
　　
　　if properly applied, the rules of continuous delivery can effectively limit the number of products, and automated deployment helps to break the limitations of the work. In this way, continuous delivery allows software development teams often deliver a higher quality product, without having to choose between the two. However, as only focus on the scrum team may overlook the broader agile environment that only focus on the team will miss the continuous delivery of a wider range of DevOps environment.
　　
　　Continued delivery practices will not solve the communication problems between the business sector and the development team directly. If the business department set up a one-year budget plan to drive, so each time after product delivery team to deliver products need to wait several months to get the business sector to feedback. These are some of the feedback usually affect sexual function follow-up steps, such as canceling projects or, worse, is the need to expand the project team (because of the influx of newcomers will affect the stability of the existing team).
　　
　　Agility fluency model "value focus" first level regarded as fluency, that team needs to focus on transparency and consistency. If the value is not focused, it is easy to fall into continuous delivery of technical improvements infinite cycle of death and unable to deliver substantial value to the business. The team may be good at high quality fast delivery, but the product itself, there may be little value to the end-user or enterprise. Even if many users are given a better rating, but a large portfolio perspective might assess a low value. Therefore, there is no value to this important focus fluency, team difficult trade-offs between technology and functionality.
　　
　　This is particularly important for the team to have a legacy code base, because the legacy code base may not be suitable for automated testing or frequent deployment design. In a legacy environment, continuous delivery conversion may take several years. Therefore, to prove the commercial value of the product is particularly important.
　　
　　Sudo install gunicorn PIP3 1.
　　
　　2. cd to django project python3 manage.py the migrate sudo
　　
　　3. start the service: sudo python3 manage.py the runserver 0.0.0.0:8000
　　
　　4. Use gunicorn to run the project
　　
　　Note: The project name Untitled
　　
　　[root @ Untitled qqc_os7] -b # gunicorn untitled.wsgi 0.0.0.0:8000
　　
　　[2019-08-04 09:31:17 +0800] [16614] [the INFO] Starting gunicorn 19.9.0
　　
　　[2019-08-04 09:31: +0800. 17] [16614] [the INFO] Listening AT: http://www.xcdeyiju.com 0.0.0.0:8000 (16614)
　　
　　[2019-08-04 09:31:17 +0800] [16614] [the INFO] worker the Using: Sync
　　
　　[2019-08-04 09:31:17 +0800] [16617] [INFO] the Booting worker with pid: 16617
　　
　　5. process View
　　
　　[Untitled qqc_os7 the root @] PS # AUX | grep 8000
　　
　　the root 0.2 1.9 213 440 19028 15383 PTS / S. 3 /usr/local/python3/bin/python3.6 + 19:27 0:00 / usr / local / to python3 / bin / gunicorn -b 0.0.0.0:8000 untitled.wsgi
　　
　　the root 0.2 3.3 256 572 33676 15386 PTS / S. 3 /usr/local/python3/bin/python3.6 + 19:27 0:00 / usr / local / to python3 / bin / gunicorn Untitled. -b 0.0.0.0:8000 WSGI
　　
　　root 15389 0.0 0.0 112676 992 PTS / 2 S + 19:30 0:00 grep --color = Auto 8000
　　
　　6. kill the process
　　
　　[root @ qqc_os7 untitled] # ps aux | grep 8000 | grep -v grep | awk '{print $ 2}' | xargs kill
　　
　　view open ports: firewall-cmd --list-ports
　　
　　open port: firewall-cmd --zone = public --add -port = 80 / tcp --permanent (open when the external network access port)
　　
　　to view the network: ping 10.0.0.130
　　
　　visit: http: //www.yisheng3yul.com 10.0.0.130:8000/index/
　　
　　! [] (https://www.hxyl1618.com img2018.cnblogs.com/blog/1357260/201908/1357260-20190804092940438-114633478.png)
　　
　　DevOps automation is not just the deployment pipeline. In other words, DevOps approach requires "maintenance staff (Ops) be able to think like a developer (Devs), and developers (Devs) have to think like operation and maintenance staff (Ops)." The following is the view of further and describes three methods can be used as DevOps principles:
　　
　　first: systems thinking emphasis on performance of the entire system, rather than the performance of a particular job or department of island - the system can be large enough to cover the entire business sector, to include only a single small work items.
　　
　　The second: the expansion of the feedback loop to create a feedback loop of the whole process. The purpose almost all process improvement programs are designed to shorten and strengthen feedback loops to ensure that you can continue to make the necessary corrections.
　　
　　Third: continue to practice and learn the culture shaping one kind of culture focused on two things: the constant practice, the courage to take risks and learn from failure; to understand that repetition and practice is a prerequisite for the master.
　　
　　Continuous Delivery focuses on the first approach: that is achieved from development to operation and maintenance of automated processes. On the role of automation to speed up the deployment of the system is obvious, but by no means thinking beyond the automation system.
　　
　　The second method is the outstanding feature of the practice, known as "developers have to carry a pager." While developers may not really want to carry a pager call to do, but they also need to actively participate in the operation and maintenance work. This will allow developers to understand the choices made to bring the subsequent impact of their development process. For example, your log messages do it enables developers to store even better position to make them play a greater role. Developers not only to understand the operation and maintenance work, but also with their own understanding of the system to do some troubleshooting work, so you can more quickly find and implement solutions.
　　
　　A third approach emphasizes incremental test the entire system, not just an application movement of the change in the pipeline. In other words, the time required to see and automation with increasingly powerful infrastructure to continue to improve it is relatively easy. And to know exactly how the transition between roles or business extension lead is more difficult. This means that the team should "check and adjust" the entire delivery workflow for points that can improve the efficiency of staff collaboration. For this problem, sustained delivery requirements team to develop the habit of constantly adapt and improve. If the team never want to think about how to become more efficient, and then taking action to adjust and improve, we can not continue to deliver sustained development and improvement. Team to believe in their ability to solve their own problems.
　　
　　In the scrum, each review conference is an opportunity to improve practices and tools. But if the team did not seize the opportunity to address short-term and long-term technical issues, they are tantamount to wait for Product Owner will continue to deliver the task into their backlog in fact, Product Owner will never do so.
　　
　　DevOps Agile beyond software application development team
　　
　　Scrum mainly follows "is pleased to face changes in demand, even if the change occurs later in development. Agile processes harness change it is to help clients gain a competitive advantage," the agile principles.
　　
　　While continuing to deliver the agile principles to follow is: "Our primary task is through early and continuous delivery of valuable software to meet customer demand."
　　
　　This means more emphasis on quick changes in input and output, rather than the daily ritual will stand and sprint planning sessions. In fact, the "Agile Manifesto" there is another 10 principles. We should treat them as a whole rather than choose certain principles. Because these principles together represent DevOps agility and attitude toward change.
　　
　　DevOps aims to change attitudes about agile applications to new areas: IT operations.
　　
　　These people have been running for enterprises is very important, but at the same time very fragile system. It is also because of its importance, so it is most urgently needed is improved. So here we are not quick to emphasize changes "in order to change and change." To allow developers responsible for the quality change, while improving the overall delivery of business value. And this focus on business value and agility is another common point of DevOps.
　　
　　Finally, Agility and DevOps itself is not business metrics. They all can inspire organizations to achieve the goal of better ways of corporate culture. Agile and DevOps in combination can achieve better results. The trick to avoid the conflict of the two cultures is to understand the composition of their deeper values and principles. Arbitrary and narrow definition would imprisons the mind. I believe after reading this article, you already know that agility is not limited to scrum, and DevOps is also not limited to the continuous delivery. Then the next, you can try the powerful combination of Agile + DevOps.