Wonder woman geek

Puppet vs Chef: A Quick Comparison To Know The Differences

WHAT ARE USER STORIES? User stories are great to capture product functionality from the end users’ perspective. They clearly show what a specific user type can do with an application. Each user story defines the following: User type (for example: admin) User’s intention Value they get (from a specific functionality/feature) User stories can be structured in the following ways: Epic (contains more user stories; should be decomposed into smaller stories) User stories Smaller sub stories (more details about the stories) WHY DO YOU HAVE TO CREATE USER STORIES? Here are some reasons: Clarifies software functionality Easier to understand Easier to remember Easier to express business value Makes  product prioritization  easier PROCESS OF CREATING USER STORIES 1. VALIDATE USER NEEDS The very first step you have to take is to clearly define the users who will use your product. It means you should create  buyer personas  ...

Let’s look at what all of this means in terms of Kubernetes applications. Principle I. Codebase Principle 1 of a 12 Factor App is “One codebase tracked in revision control, many deploys”. For Kubernetes applications, this principle is actually embedded in the nature of container orchestration itself.  Typically, you create your code using a source control repository such as a git repo, then store specific versions of your images in the Docker Hub, ECR, ACR. When you define the containers to be orchestrated as part of a a Kubernetes Pod, Deployment, DaemonSet, you also specify a particular version of the image, as in: ... spec:      containers:      - name: AcctApp        image: acctApp:v3 ... In this way, you might have multiple versions of your application running in different deployments. Applications can also behave differently depending on the configuration information with which t...

Go and Test: Cucumber This if the first post of a series of three: Cucumber in Go with Godog Testing with GoConvey solution Mocking. Cucumber in Go with Godog When you begin to work with a new programing language, after you know the syntax and structures of languages, the next step write code. To write code It is necessary to know the testing tools that you can use with the language. This post addresses the tools that I use now with go. In Fexco we believe that first thing that you must do is to define the test and then to write the code. The reason is that we follow the paradigms BDD and TDD. We always define the features that our code must accomplish. The objective is for our code to have a good coverage and then it will do what it is designed for. That is the reason why we write in gherkin what we want the code to do. Writing the test before has something that I specially like: when an bug is discovered in code, the problem is not the code, the problem is that...