GitHub GitHub Universe 2020: Enterprise - DevOps, 10 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Managing test environments with GitOps and Actions - GitHub Universe 2020

Description

Presented by:
Andreas Prang, Team Lead Infrastructure Services, Axel Springer SE
Daniel Fassbender, Senior Software Engineer, Axel Springer SE

This talk will cover how to build a setup that creates a separate development and test environment, using BILD.de — one of Europe's biggest news sites — as an example. Through the combination of GitHub Actions, Container Registry, and GitOps, these Phoenix Environments can be set up in less than 200 lines of code, providing individual test environments automatically within minutes. The benefit: Your developers are able to show a preview to stakeholders with just a few automated and manual tests.

For more from GitHub Universe 2020, visit https://githubuniverse.com

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub

Thanks!

Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

Hi, I'm andreas, I'm the team lead of our infrastructure and services team here at axospringer, national median tech.

A

Our team is creating an infrastructure platform to give our developers the possibility to run their services easily for our platforms like blte and valde, some of the biggest news portals in germany and europe later on, I'm happy to be joined by daniel one of our senior devops engineers.

A

Today, we want to share our solution on how to set up completely automated test environments in kubernetes, using githubs and the github toolchain.

A

When developers start with a new feature, they want us to spin up a complete new test environment and when the last pull request has been merged to the main branch, they close the feature branch and want us to destroy the test environment completely, to avoid any costs afterwards.

A

So this kind of test environments are called phoenix environments and for those phoenix environments we do have two stakeholders at first they are the developers they list their code changes as close as possible to production, and so they can avoid conflicts on parallel development in different features, but the same project. The second group are the product owners.

A

They want to have these phoenix environments to test and approve new features before going live, and to do so, we give them a unique url for each phoenix environment, and why do we want to be as close as possible to production?

A

We could do it the either way and just create a new namespace and kubernetes and deploy a few services and have a look, how it's working, but what we do is to create a copy of the complete live environment, including all monitorings, loggings and many more services we have in place for our production system before we dive into the workflow. I want to give you a very short introduction into githubs, which is a combination of infrastructure requirements defined in yaml files and saved in a github repository and a service running in kubernetes.

A

In our case, it's flux, cd, which continuously is watching the infrastructure repository and whenever any changes occur, these changes will be applied to the kubernetes cluster.

A

The benefit for us to use githubs is to get rid of old-fashioned toolings like jenkins having complex, ci, cd pipelines and discussions within the teams who is responsible on which part of this complex cicd platform.

A

I set up the development teams to just be responsible by creating the new image for the service testing it and uploading the new docker image to the github container registry.

A

Now, let's dive into our workflow, let's say one of our developers want to start creating a new feature. The first thing he will do is to create a new feature branch, and by doing this in behind a github action, a very small one inside of the repository will be triggered by the oncreate event.

A

This one grabs the right informations out of the feature branch like the feature, branch name and the project name and hands it over to a more centralized. Github action which takes these info grabs, pulls the right flux, cd repository where all the definitions for the live environment are in. It takes the yummy files, creates a copy, replaces some values and pushes those new files back to the github flux. Cd repository by doing this now the flux cd service will notice.

A

Oh, there are some changes and these changes to the kubernetes cluster, creating a new feature namespace and set up the kubernetes resources, like secrets, the configuration map, and by doing this it tells the ham operator to deploy all services needed to run this new test environment.

A

These are the main features of our setup and to tell you about all all others features and look have a look into the code, let's hand over to daniel daniel.

B

So, thank you. Andreas.

B

And you want to share a screen.

B

And here we go so um now we will perform a demo of a life cycle of our feature, branch and its corresponding phoenix environment, and we do this. From the perspective of a developer, some looks behind the scene of the creation process for phoenix environment.

B

So first, let's assume we got a ticket from our product owner to implement video embeds on our news page. So our ticket has a number- let's say it's abc -123 and that will be used as a label to identify our phoenix environment.

B

So first we start in the terminal and uh we are locked in and one of our kubernetes clusters and we will check if there still exists an environment with this label.

B

So we display all our available name spaces here. As you can see, there is no namespace uh for a phoenix environment with a label abc minus one, two three.

B

So then we go over to the browser and we will have a look on the production state of our news page. So, as you can see, there's just twitter embed, but the product owner says he wants to have a video embed above the summary.

B

So as a developer, I go to our code repository and make there some small changes on the code.

B

And I commit this on a branch with the name.

B

Turn picture minus abc minus one, two three and have a short description here.

B

So, with a commit um to this branch, we've triggered two actions in our project, so the first one is the ci pipeline of our project look inside and what we see. We built a docker image and push this to the github docker registry and we use the github api to create a deployment for our commit and set the state of this deployment to state queued.

B

So we will come back to this deployment later. First, we go to our second action and the second second action is a trigger for our creation process of the phoenix environment.

B

We just collect some informations about the phoenix environment. We want to create and add this, this data to a payload and create a dispatch workflow event for on the github api, and with this event, we trigger another action in our github flux, cd project and this action takes the um the data from the workload as input parameters, and then it checks out the repository and runs this group to create our phoenix.

B

And finally, it pushes back the data, the changed files to the github repository. So let's have a closer look on this script.

B

We use here so, let's create phoenix and first we start and make a copy of the production definition of our github demo project then use some tools like yammer query and, in this case, set customize these yummy files. So we set the namespace for our phoenix and we add the phoenix name as a label to the urls of our project.

B

And finally, we add the created files to it.

B

So the result you can see here we created a new folder for our demo application or phoenix demo application, and then we switch over to the terminal again and let's see like fluxiv on its job so list the workspace, the namespaces again and you can see github demo feature minus abc minus one to three namespaces created and we will look what's inside.

B

As you can see, there are some parts and the service, and you see our system is up and running and we go to the browser now.

B

So you can use this test for automated test scenarios at this environment, like end-to-end tests or for manual tests of your qa department or your product owner or stakeholder, can make some approvals here. So we will adjust the url a little bit for this manual test. So we are on a test cluster now and it's another feature.

B

As abc minus one, two three label and fire- so you see the same article here, but we got some new elements here. A video embed above the summary.

B

So then we go back to our github code repository and first, I want to show you the the benefit of the deployments we have created in our ci process. So you can see a list of the environments of all the of all environments. You have deployed your application to you can see here. Our new created phoenix environment go in there, see okay, this commit was deployed here and there's another benefit you see in the main environment.

B

You also get a history of all your deployments there and the final state they have reached so audio we're inactive and the new one is active here.

B

So then we finally reached the end of the life cycle of our feature branch. So usually we want to go here and say: okay, we make a pull request. Then we merge this progress to the master or main branch now and then we delete our feature branch so for the demo we just just delete it and with this deletion we triggered a new action for deleting a phoenix you look inside it's similar the same as uh on the creation creating creating process of our phoenix.

B

So we collect some informations, create a payload of this and make a workflow dispatch event, and what we also do here is right back. We remove all the deployments we have created for this phoenix environment.

B

So that's the first one we see here the environment is gone, so we need it anymore and then we go to our flux, cd repository and here's also an action triggered for destroying the phoenix.

B

So nearly nearly the same as creating so you check out our repository run, a script for destroying the phoenix and then push back. The changed files to github also have a look at the script we use here.

B

That it's short script, just removing a folder from our project and if it's work you can see it here, let's remove there.

B

So then we can go back to the terminal, clear it and then flux should have removed our namespace here so and we have removed the namespace, and so we finally reached the.

B

The end of the lifecycle of our demo project and also of our demo, and we go back to andreas and our.

B

A

Okay, thanks daniel.

A

So let's go to our last slide here we are.

A

A

Okay, so let's sum up what we achieved, we achieved to have a setup with less than 200 lines of code and with this setup, which is very dynamic, we can your many product projects and services.

A

It's completely automated and it's completely close to a production and which technologies are we using we're using kubernetes, fluxity and out of the github tool chain. We are using github actions, the container registry, the deployment api and the repositories that, having said, we are looking forward to your questions.