LocalStack is a fully functional mock of AWS services running locally on your computer. We can use it to develop and test cloud and serverless apps offline. It can run through the CLI, in a Docker container, or in a Kubernetes cluster. We can use it to create mocks of S3 buckets, Lambda functions, RDS databases, ECR repositories, and more.Continue reading
The video below is a clip from the "Canary Deployments To Kubernetes Using Istio and Friends" course in Udemy. It provides the introduction to the course we released in December 2019. Additional preview clips are available inside the course. Please use the coupons with discounts provided below.
If you do enrol into the course, please let us know what you think and do NOT forget to rate it.
$9.99 coupon available until December 30, 2019: https://www.udemy.com/course/canary-deployments-to-kubernetes-using-istio-and-friends/?couponCode=66C518BC01D2339CABCB
$13.99 coupon available until January 27, 2020: https://www.udemy.com/course/canary-deployments-to-kubernetes-using-istio-and-friends/?couponCode=7F311AD2C040117054AB
Coupon with whatever is Udemy’s best price: https://www.udemy.com/course/canary-deployments-to-kubernetes-using-istio-and-friends/?referralCode=75549ECDBC41B27D94C4
Welcome to practical guide to canary deployments. Unlike some other work that I did…tutorials, workshops, and so on and so forth, that were very focused on a single tool, this time I will focus more on a process.
We’re going to try to figure out how to do canary deployments inside of Kubernetes. Because Kubernetes is everywhere now, I will assume that you are using Kubernetes. But outside of that, we are going to try to figure out which tools to use, but all serving as the process itself, not for the sake of learning a specific tool. And during that process, we are going to decide which tools to use and why to use them and the end result will be a fully operational canary deployments process that you will be able to plug into any CI/CD tool or any tool that orchestrates the lifecycle of your application.
So we will definitely choose some tools that we will use in a process.
And those tools will be revolving around Istio. I will explain why Istio a bit later.
So we will use Kubernetes and Istio for canary deployments, but the end result will be agnostic to the tool that will orchestrate your processes. We will most likely also have to choose one or two additional tools. Which tools we’ll choose is yet to be discovered.
For now just think of this as being a practical guide to a specific process. And that process today is canary deployments in Kubernetes.
What is Test-Driven Development (TDD)?
Test-Driven Development is a process that relies on the repetition of very short development cycle. It is based on the test-first concept of Extreme Programming (XP) that encourages simple design with high level of confidence.
The procedure of doing TDD is following:
- Write a test
- Run all tests
- Write the implementation code
- Run all tests
In this article we’ll go through the exercise of writing a method that will write string content to the specified file. There will be an option to specify whether we should overwrite an existing file. In addition, directories should be created if they do not already exist.
Programming language is Scala and testing framework that will be used is Specs2. In the spirit of unit testing, instead of interactions with the file system we’ll use mocks with Mockito (already included in Specs2). All the code will be done using Test-Driven Development (TDD).
Let’s get started.
This article is part of the Continuous Integration, Delivery and Deployment series.
Behavior-Driven Development (BDD) is a process or it can be a tool. In many cases, BDD is both. However, it should not be a goal in itself. The goal of software development is to deliver quality as fast and as cheap as possible. The only real measure of quality is whether it fulfills user needs in a reliable manner. The best way we can take to accomplish that goal is through continuous integration, deployment and delivery. For the sake of this article I will ignore the differences between those three and refer to all of them as continuous integration or CI.
Documentation needs to be comprehensive, always up-to-date and accessible. By comprehensive I mean that it must cover all important areas of the code as well as all functions of the application. While importance of documentation is obvious to most, many struggle without success to have it accurate and up-to-date. Response to “poor” documentation is often assignment of more resources and more time. More often than not, documentation is created for wrong reasons.
A typical waterfall project has well defined phases that go from the idea conception until putting the solution in production, being the most typical of them:
- Requirements gathering
- Design of the solution / Architecture
- Testing phase (including all kinds of tests)
- User Acceptance Test
- Go Live (put in production)
- Post Go-Live support
It’s very common in big companies that there’s a functional team responsible for each phase. Thus, we get:
- Business Analysts to gather requirements
- Architects, Systems Engineers or Software Analysts to design the solutions
- Programmers or coders to implement it
- Quality Testers or Quality Assurance engineers to check its quality
- The customer to test the delivered solution
However, one of the big problems from this approach is that usually these teams work in silos. The right hand doesn’t know what the left hand is doing and this causes inefficiencies. To make it worse, sometimes the way to try to reduce silos is through an immense increase in bureaucracy, forcing teams to communicate through documentation.
DISCLAIMER: This is not a tutorial on how to learn Python, in fact, I have never used Python before so don’t take me as example. What I want to share with you is how to learn a new language, strenghen the TDD principles and practice a Kata in an easy way.
Last week I attended the Global day of Code retreat in Barcelona. It was a wonderful experience that generated me a lot of energy to code again (I became a manager some time ago and I don’t code as often as I’d like to). That day we used the Conway’s Game of Life which I recommend to practice the TDD approach.
After investigating about several other katas I stumbled upon the Cyber dojo online tool. Basically this is a web page in which you can practice any kata and choose among more than 20 languages you want to learn without the need to do any setup at all. In other words, if you want to grasp the basics for a new language, this is the perfect place.
Also, one of the nice features from Cyber dojo is that after you’re done with all the coding you wanted to do, you can download all your changes into a zipped Git file and then you have the repository with all the changes that you worked on.
In the previous article Test Driven Development (TDD): Example Walkthrough an example of TDD was given. It went from writing first test and its implementation to having a set of requirements fully tested and developed. Now it’s time to learn what the best TDD practices are. This article will be built on examples from the previous one.
Best practices are solutions to a set of problems under certain situations. Not following them would make us “reinvent the wheel” and struggle with the same problems already solved by others. On the other hand, best practices should not be followed blindly. They should be tried out. With an informed decision at hand, they can be adopted as they are, modified to serve better specific situation or fully discarded.
Some of the best practices described here are inherited from other sets of practices and used when doing TDD. For example, most (if not all) unit testing practices should be used when doing TDD.
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
The following sequence of steps is generally followed:
- Add a test
- Run all tests and see if the new one fails
- Write some code
- Run tests
- Refactor code
There’s a plenty of articles written on TDD and Wikipedia is always a good start. This article will focus on the actual test and implementation using variation of one of the Roy Osherove Katas. Do not click the link until you’re finished with this article. This excercise is best done when not all requirements are known in advance.
Below you will find the test code related to each requirement and afterwards the actual implementation. Try to read only one requirement, write the tests and the implementation yourself and compare it with the results from this article. Remember that there are many different ways to write tests and implementation. This article is only one out of many possible solutions.