Shulou(Shulou.com)06/03 Report--

Due to the relationship between the work areas, more or less attention will be paid to the relevant areas of DevOps topic at present. Of course, various tools and combination methods suitable for continuous development and continuous integration are still being tried. My superficial understanding is that DevOPS is actually not only an area that developers need to pay attention to, but also an area that operation and maintenance personnel should pay attention to, because the future IT world is actually a "relatively mixed" space, and the development speed is faster than imagined. In terms of tools in the development and testing field, Chef/Puppet/PowerShell DSC, widely used in the open source field Salt Stack, Ansible to Docker ecosystem, etc. encapsulate a series of infrastructure, that is, the emergence of code and other concepts, reminding us all the time that the essence of the power behind evolution is the continuous improvement of the ability of the business to the IT system. For example, application functions need to be realized through continuous development and continuous integration. Rapid improvements in code iteration agility; to achieve these goals, a large number of Internet companies have begun to take the lead in practice, of course, not necessarily full stack practice; but at least in some areas have accumulated a lot of experience, and began to split the next big application structure into a fine Restful API structure, independent operation and extension, and delivered through the gateway cluster microservice structure; In the process of such a large field change, the change of the development and operation environment cannot stand still. If you don't advance against the current, you will retreat. If you are still satisfied with a few mouse clicks or expect to explore standardized IT services in complex IT systems, it is obviously a bit outdated. This may not be a question of "survival" or "destruction," this is an era in which only games have the opportunity to participate, so willing or unwilling, as IT practitioners may have to start exploring and learning. The initial practice of continuous development and integration, I think, starts with tool selection; To achieve a high degree of automation must start from the principle of simplicity, development, transition environment and production environment generation and change, can be based on code Build version control change or initialization triggered release process, supplemented by a set of parametric structure through simple declarative packaging (Similar to the yml file in the open source field, the configuration file of PowerShel DSC, or the ARM template in Azure, or the Dockerfile, of course, may also be the menu rb configuration of Chef), through the standardized Provider driver for the configuration of the cross-environment standardized execution process; a continuous integration prototype came out; Gradually, the upper structure is supplemented by approval, resource registration, lifecycle management and tracking, so a relatively rich DevOps technology tool stack for development and testing is gradually completed; finally, the process of gradually evolving from application development to microservice architecture design; the final effect to be achieved is naturally continuous development and continuous integration; Adapt to the rapid expansion of business and iteration of functions, and reduce the drag and impact on business caused by a series of problems such as loss of basic structure, inadequate configuration change or overall rollback caused by large-scale regression testing; Therefore, in fact, challenges are also opportunities. Why did the vigorous development of Taobao business system once drive the great gods of various "name lists" surging, and why did so many masters be created in the open source era now? Why is it that as an IT operations person now, Python and other languages and frameworks are respected? Do you feel the power behind all this as practitioners? If so, then brave people always have the opportunity to try and eventually stand at the structural peak, in short, I believe...

Anyway, here is Azure International as an example; trying to describe a simple continuous integration process practice that will publish updates from on-premises Git or GitHUB source code control and repository tools for continuous integration Web applications into Azure, although Azure can also be used to switch back between production and transition environments; It should be noted that Azure public cloud is developing very rapidly. In addition to the website applications used here, mobile applications, API applications and even microservice logic applications can be integrated with the above Git source control libraries such as Codeplex, TFS, Bitbucket, etc. with the help of Microsoft App Service.

Step 1, done locally

First, we need to make sure that the local Git environment is available, and choose the appropriate Git client depending on whether your system is Windows or MAC.

Next, open the local Git environment, Windows can directly use GitBash

Create our test WEB project directory, enter and initialize the local Git library,

cd C:\Users\shzhai.FAREAST\Documents\GitHub\TestWebCIRepo

git init

Our project is as simple as possible, just to test the code release and continuous integration process, so here we first create a default static page in the project,

echo "My Demo page! " > .\ index.html

Now add the page to your local Git repository,

git add .\ index.html

We commit changes and add comments to the local repository,

git commit -m "Add the first static page to local repo! "

Step 2: Set up the Web App Library on Azure

First, we added a Web application MyCIWebDemo to the new portal for Azure International;

Select Continuous Integration, select Source as Local Git Repository,

Next, set up user credentials that require persistent deployment

Step 3, now start deploying your on-premises test project to Azure Web Apps;

First of all, in the deployment area, we haven't seen the deployment of local Git libraries yet;

Next, we select Web App Properties or click Deployment, go to Properties Settings Select Azure Remote Git Deployment URL,

We now go to the local Git console, add the Azure remote Git URL we just copied and make the remote Git connection named Azure.

git remote add azure https://shawnzhai@myciwebdemo.scm.azurewebsites.net:443/MyCIWebDemo.git

Next we push the local master version code to Azure remote Git and enter the user deployment credentials we set up earlier;

git push azure master

We can see the deployment just pushed in Deployment of Web Apps in Azure;

Click on the deployment link, we can see just deployed static page displayed;

Now we modify static pages in the local project directory;

echo "New CI Demo! " > .\ index.html

git add index.html

git commit -m "Check in New Page"

git push azure master

Go to the Web page again to see that Dida has changed; the actual environment integration will add deployment slots for transition testing; we will introduce this part in another article;

Finally, let's experience continuous integration with GitHub instead of an on-premises Git repository through Azure Web apps; if it's not just on-premises development projects, but team collaboration project versions published to GitHub, the benefit of continuous integration is that collaborative projects, regardless of who ends up doing the update, are only integrated with the latest project versions in the GitHub repository published to Azure Cloud.

Start by hosting the code on GitHub,

Next we need to select GitHub on the Azure Web App Continuous Integration side;

Select Authorization, redirect to Github Allow proxy authorization access to Github for Azure; Next select GitHub Organization for project selection;

Next select the GitHub project and fork settings you want to deploy;

When we confirm, you can see the deployment process in the notification area;Azure will check out and deploy from the GitHub project branch;

View deployment results and verify;

Conclusion, in fact, continuous integration of development and testing environment is a very large topic, involving people, processes, tools and a series of content; this article only explores the tip of the iceberg, but to do good work must first sharpen its tools, Azure public cloud architecture in the design of the full consideration of continuous development integration, deployment and a series of related issues, in the tool end to strive for compatibility and perfection; let us continue to explore it slowly!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.