“Simply push your code.” What does that mean, exactly?

“Simply push your code.

amazee.io builds, hosts, scales, and secures your sites and apps.”

We’ve got this sentence on our website’s homepage. And if you’re a more technical person, a developer or engineer perhaps, you’re probably following along.

But in today’s blog post, we want to break down exactly what we mean when we say this - for all audiences, technical or not. 

Before we can discuss what it means to push code, we need to help you understand repositories and branches. 

What is a repository?

A repository is a specific way of storing your project's code and all past files relating to the code. Repositories are a part of GitHub, GitLab, and Bitbucket. They contain all of your project's source files, and a revision history of every file is stored in the repository. Every single version of your code is stored in the repository, which means you can go back in time and see what changed in your files over the course of time - down to the last detail. 

What is a branch?

A code repository is made up of one or many “branches.” A branch is a unique set of version changes for your files, and each branch has a unique name. Generally speaking, the “main branch” will be the place where all changes are merged into. So your main branch will often be the “official working version” of your project, and the most up-to-date. 

Branches are important for the amazee.io platform because each branch can represent a working version of your project. Perhaps you would have a branch called “new newsletter subscription” which has only the code for building your new newsletter subscription page. 

All the work could be done in this branch, tested in this branch, and ultimately when you are ready, you merge the branch into your “main” branch as a way of getting your code from a non-production environment to a production environment.

Now, let’s look at the amazee.io process, starting with “simply push your code.” 

What does it mean to “push” code? 

The term “push” refers to the act of sending, or uploading, code from a branch in your local source code repository to a branch in the remote repository - no matter where that may be. Code pushing, a GitHub-coined term, is the way to transfer your code from where you created it into a location where it can be used. 

In some cases, “pushed code” can simply mean an update. New code was created and moved from a creation environment (often on a developer's laptop) to the targeted environment, and the result is an updated website, app, or product. 

There can be different definitions for the term “code push,” but when we use it, we mean that code is being sent from a creation (or local) environment to a hosted environment. The code has been finished and now is moving into its final location, where it will be functional and used. 

When code has been pushed by developers, this means it’s now in the online code repository where it can be used. Now what? 

Here’s what amazee.io does next for your sites and apps. 

Firstly, it's important to know that pushing the code is the last thing the developer needs to do manually. The automation takes over from here. Once you push your code, the developers’ responsibilities end there. 

As soon as the code is pushed successfully to your code repository (such as Github, Bit Bucket, GitLab, etc) the repository software notices the commit (version change), and sends a message to our platform, informing us that new code has been committed into the repository. 

So after developers push the code, our system notifies us that new code is available in the repository. 

From there, our platform interrogates the message to see if the branch is reporting a change that we need to worry about. Developers are able to tell our system about branches that should trigger an environment to be created. Branches should not trigger an environment creation automatically, because you won’t want an environment for every single branch.

If the branch being pushed to is one that our platform should care about, the system triggers the build process.

So what are we building for you? Container images - are a crucial part of improving your site and app hosting. 

A container image is a ready-to-run software package containing everything needed to run an application, including the application code, any supporting runtime dependencies that it requires, and default values for any essential settings. 

Container images can run isolated processes on your IT infrastructure, and it’s a standalone software package with everything you need contained inside it. Here’s how it works: 

Downloading the branch. The build process involves our platform downloading (or cloning) a copy of the branch that was changed into the hosting environment. 

Interrogating the files. The platform then interrogates the files where the developer has described what they need for a hosting environment. For example, their developer would define a database server, a web server, a PHP server, or perhaps a SOLR or Elasticsearch server. Whatever they select, our platform can work with them. 

Finding definitions and building infrastructure. Next, we find all the definitions requested and build out the infrastructure for the project as docker container images.

Storing in a container registry. Once the containers that are defined for the environment are built, they are stored in a container registry (which is essentially a library of all the containers that your application needs to run). 

Kubernetes launch. After storing the containers in a library, the platform instructs the container-orchestrator (Kubernetes) to launch a version of your application. This means that the platform instructs Kubernetes to launch your containers and get them ready to serve the site or app. 

(Kubernetes is an open source container orchestration platform that ensures applications in cloud environments run consistently by automating operations such as deploying, scaling, and managing containers or clusters. To learn more about Kubernetes, check out our blog exclusively on this topic.)

Directing traffic to new containers. Once the containers are started successfully, the web traffic to your site or app is directed to the new running containers.

Up to this point, the developer has only taken one action - by pushing the code. Our platform has done the rest with quick and easy automation.

The amazee.io automation process 

The developer is notified about the progress of the automation in two ways: Firstly, our platform is integrated with Slack, Rocket.Chat, and Microsoft Teams, as well as email and custom webhooks. When the platform starts a build, the developer gets a notification. If the build succeeds or fails, the developer is notified.

If a developer wants to track the automation process and see more specifics, they are able to do this by logging into the amazee.io platform web interface (dashboard.amazeeio.cloud) and following the logs of the automation processes.

The results

Just by pushing their code, the developer has triggered a full automation process that downloads the code, creates the containers, starts them up, and redirects the traffic. The result is a fully production-ready hosted version of the application running in containers in a Kubernetes environment. 

Why Kubernetes?

Kubernetes is self-healing: Kubernetes restarts containers that fail, replaces containers that need it, kills containers that don’t respond to health checks, and doesn’t advertise them until they are ready to serve.

Kubernetes enables scaling: Kubernetes autoscaling helps optimize resource allocation and budget by automatically scaling a cluster up or down in line with demand. 

What is going on under the hood in the automated processes?

The automation is powered by Lagoon, the open source application delivery platform for Kubernetes built specifically for the web and its developers, providing projects with all the configuration, tooling and insights needed to run in production at scale. 

Lagoon enables global teams to scale on the infrastructure of their choice without requiring knowledge of Kubernetes. 

To find out more about Lagoon visit lagoon.sh

Fully open source technology 

While Lagoon was originally conceived and developed by amazee.io, it was fully open sourced in August 2017. While amazee.io still leads the open source project, there are now many skilled developers outside of amazee.io contributing to the platform. And because Lagoon is open source, developers can easily integrate Lagoon into their own CI/CD workflows and processes.

Removing creative bottlenecks and limits from web teams 

The business impact of working with amazee.io and using our platform is focused mainly on web team function. With our managed Kubernetes solution as outlined above, developers will save so much time, and they won’t have to walk through manual steps of every update or change. 

This means that web teams and business leaders can do things faster, with better time to market, creative freedom with no bottlenecks, and cost-efficient scaling. Web and marketing teams can experiment with new ideas, updates, and landing pages in minutes, not days. 

Managed Kubernetes takes the pain out of deployments, which means that marketing and business ideas can become a reality much more easily. Automation makes all the difference - it speeds up the mundane tasks that would have taken developers days or weeks to finish. Instead, you’re looking at minutes or even seconds. 

amazee.io’s skilled Kubernetes team manages thousands of workloads on dozens of Kubernetes clusters across the globe. 

We handle all upgrades and fixes, so your team is completely freed of all management burdens. 

Another day without Kubernetes is another day wasted doing things manually - and there’s a better way, we promise. 

To start automating with managed Kubernetes and saving time and valuable resources, reach out to our expert team for a free 15-minute consultation today.