Demo: Idea to Production скачать в хорошем качестве

Demo: Idea to Production

Transcript Today I’d like to demo some of the power of GitLab’s integrated set of tools for the software development lifecycle, helping you get from idea to production as quickly as possible. We will start with a simple project and will show you the power of built-in continuous integration, built-in container registry, and built-in continuous deployment. Here’s a simple Ruby application based on the Sinatra framework. If we go to the production site, we can see that it just display a single page. Now, as a developer, I’ll look at the project’s Issue tracker to see what I need to work on. I see there’s an issue here, let’s click on it. It’s asking to change some text; seems pretty straightforward. And look at that, there’s a proposed merge request already. Let’s take a look at that. Here’s we can see the exact code that has changed and discuss it. But I don’t just want to trust reading the code, I want to see it live. Let’s go back to the project and we see a link to the staging server where this merge request has already been deployed. Now this is great, I can see the change running live, but I realize I’m not really happy with that. Let’s make another change. (make changes) Now that we’ve made a change, it kicks off a bunch of automated processes to build, test, and deploy that change. Let’s follow the progress. [Refresh until Builds tab reappears, then click on it] The first step is to make sure all the unit tests pass on GitLab CI. Now that that’s finished, it goes on to build the docker image and push it up to the integrated GitLab Container Registry. The docker build can take a while, so in the meantime, let’s take a look at the container registry where you can see there’s already a bunch of images, including a couple special tags for `staging` and `production`. Back to CI, if the build succeeds, we take the docker image and deploy the application using Docker Cloud. Docker Cloud is set up to grab the image directly from GitLab Container Registry and deploy it. Anyone reviewing the code can now go to the staging environment and see those changes live. We can also go to the Pipelines tab and see the history of CI build pipelines, and if there are any failures, it’ll quickly show you the stage where any builds fail. And on the Environments tab, you can see what’s currently running in staging and production. This clearly shows that while my new changes have made it to staging, they haven’t made it to production yet. Since we’re happy with the changes, let’s ship them to production! Going back to the merge request, we’ll click the Accept Merge Request button to merge the changes into the master branch, which is configured to automatically deploy the application to production. Back on the Pipelines tab, we see that we’re re-running CI on `master` to make sure the tests still pass after the merge. While we’re waiting, let’s go back to Environments. Clicking through on `production`, we see a history of everything that has been deployed to production. This is great to see what exactly has been deployed, and also exactly when changes were deployed. There’s also an easy way to rollback to one of the previous deploys. That can be a life-saver in an emergency so you don’t have to wait to write a hotfix, wait for it to be tested again, etc. Our fix should be pretty much deployed to production by now. Let’s go back to Pipelines; yep, it’s been deployed. Let’s check the environment; yep, deployed about a minute ago. Now that everything is updated and our fix is deployed, we can now go to our website and verify that the fix is indeed deployed. If we want, we can also go to the Container Registry to see that the production image has been updated.