When you’re working on code with your team, the same pain points always crop up. Repetitive, time-consuming testing and code merges causing messy deployments are a drag. But, there’s a trend in DevOps that’s gaining popularity because it eases developers’ workflow: Continuous Integration/Continuous Deployment (CI/CD).
CI/CD is an automated deployment pipeline that allows for automatic testing and simplifies code merging, among other benefits. You can even configure your CI/CD settings to ensure the code deployed conforms to your previously established application standards. In the end, you and your teams will be able to deliver small pieces of code rapidly to efficiently advance your project.
Curious to try out a CI/CD before deploying it in your production environment? We’ve put together a tutorial on how you can easily try it out using GitLab CI/CD and Docker.
GitLab CI/CD is a common tool to create a CI/CD pipeline. It allows you to automatically build, test, deploy, and monitor applications using Auto DevOps. We used Docker because it is one of the first, and most popular, containerization platforms, thanks in large part to its portability. Let’s dive into how you can create a CI/CD pipeline using Docker and Instances!
Creating a GitLab CI/CD with Docker
GitLab users can spin up an Instance using the GitLab InstantApp with just a few clicks.
- Install GitLab server.
- Install one or more GitLab Runner(s) and include configuration file(s).
- A runner is an application that runs jobs within the GitLab CI/CD pipeline housed by the Docker container, thus isolating the build from the run environment.
- The best practice is to install your GitLab Runner on a different machine than the one hosting the GitLab Instance. With the runner and the Instance separated, you will have better performance and security.
- You can use different operating systems and tools on each Instance, if desired.
- Once your GitLab Runner has been deployed with its configuration file (gitlab.toml), the CI/CD jobs can now use it.
- It’s worth noting that deploying the runner as a container will help simplify this process.
- You’ll then add a .gitlab-ci.yml file to your application’s repository which contains the source code.
- Adding the .gitlab-ci.yml file is a configuration file which describes the GitLab Runner to be used and the CI/CD pipeline steps (build, test, deploy on staging, deploy on production).
- Set the desired tests your code will undergo before the CD pushes it to your production environment. Each step of the CI/CD pipeline can run different jobs simultaneously–a very handy feature when it comes to testing.
- Your CI/CD is ready to go!
What to expect once you've launched your CI/CD
Each time the user makes a change in the GitLab repository, GitLab executes your new CI/CD pipeline with the GitLab runner, on the Instance where the runner is installed.
- The runner’s executor processes the commands in Docker containers.
- The runner executes the pipeline you’ve described in .gitlab-ci.yml. The CI/CD usually has a stage that builds a Docker image with your application and pushes the image to a Docker registry. In this case, the image is pushed to your project’s GitLab registry on your GitLab server.
- Then, another step in your CI/CD will use that image for automatic or manual deployment to the environment of your choice.
PLAY2: A sandbox environment to experiment worry-free
Ready to try out a CI/CD pipeline, but concerned about deploying it directly in your production environment?
A sandbox environment can provide an isolated virtual machine which mimics your production environment and removes the risk of an experiment going wrong. Scaleway has just debuted a new Instance range, PLAY2, whose features are specifically tailored to help developers create the sandbox environment they need.
PLAY2 was specifically designed as a smaller and less expensive version of a production environment. So deploying and scaling an application from the PLAY2 development environment to a PRO2 production environment is simple but ensures total compatibility.
Plus, PLAY2 works with one of our newest features, Boot-on-Block. Boot-on-Block allows you to add block volume anytime and on any instance, and it is 2-3x faster than local storage. Not to mention, it automatically duplicates your data across three different servers to prevent accidental data loss.
Not only does PLAY2 offer speed and flexibility, it also has many customizable options so you can create a sandbox environment similar to your production environment.
These pre-configurations for hardware, OS Images, and InstantApps (Including GitLab and Docker, of course!) let you launch your experiments without losing too much time fiddling with configurations.
Plus, once you’re satisfied your CI/CD performs as needed–no more pesky, painful testing!–you can add an extra step in the pipeline to deploy your application on your production environment, just as you did with your sandbox.
Gimme the specs!
Though PLAY2 was created to allow developers to, well, play around, we didn’t compromise on performance. We built PLAY2 with the newest AMD AEPYC™ 7003 Series processors, and Instances range from 1vCPU to 4vCPU with 2GB RAM per vCPU.
And we are not too humble to tell you…We have the best price/performance ratio on the market. PLAY2 starts from €10 per month or €0.014 per hour, which is up to 60% less expensive than similar services from big players.
Ready to begin experimenting with the next solutions and upgrades you’ll bring to your professional projects? Deploy your first PLAY2 Instance here.