I assume you already know something about agile development before you start reading this article. In the simplest way, “MOVE FAST”. Things are always easy to tell and understand, but, most of the time, difficult to execute. In this article, I am going to share how my team is working and how I clarify these things (after a huge failure, ha, anyway).

Problem

There are lots of ways to make you feel the whole work flow stuck. We are not going to discuss it one by one. Let’s just directly talk about the symptoms.

1. Cards cannot move / deploy for days
2. Cannot scale up development rate easily
3. Code pull requests stay alive for too long
4. (name yours)

To all these questions, people always say “JUST BREAK IT DOWN”.

“I did try it. It just didn’t work out”, you may say.

Thoughts

To me, there are two key factors of “BREAK IT DOWN”.

1. Small User Stories 
2. Spliting Story Ticket and Task Ticket

Small User Stories

Case 1

ONE ticket should only contain ONE user story. Actually, it’s still a vague definition. To be frank, before our whole work flow revision, I received a story ticket from the product team.

FEATURE - resource listing page
  1. clicking the create button will go to edit page 
  2. clicking the delete button in drop down will deactivate the script
  3. ... more

Obviously, this ticket is too big and includes lots of user stories. A better one will be

FEATURE - In listing page, clicking the create button will go to edit page
FEATURE - In listing page, clicking the delete button in drop down will deactivate the script

Easy, right ?

Case 2

Sometimes, we may also need to break down ONE user story into multiple story tickets, especially, when you are building a whole new things.

For example, we are working hard to build a new epic feature. Whole new frontend pages. Whole new backend structure. We made a mistake in our planning.

Our ultimate goal is to build a flow that can be triggered by keywords and give some response. We had simplified our stories.

1. FEATURE - User can setup keywords for the response
2. FEATURE - User can setup more for further response

We thought it made sense already. However, it actually didn’t. Setting up keywords and setting up response both already requires lots of data structure and new UI components since the project just start. Some of the components are required to be library standard components. It’s like building a Titanic already.

In the end, we setup straw men for a better story management.

1. FEATURE - User can setup keywords for a dummy response 
2. FEATURE - User can customised the response 

//we should even do more if we know things earlier...
3. FEATURE - User should see a keyword setup field in edit page
4. FEATURE - User should see the keyword in edit page after saving

A small conclusion here.

1. A ticket should always describe only one behaviour
2. Setting up a straw man for further breaking down the story
3. A story ticket's goal need not to be a complete use case

Splitting Story ticket and Task ticket

The second part is hard to swallow. Please be careful.

1. Story ticket is ONLY responsible for user story management. It concerns only the product team and the qa team. It mainly passes through phases like use case review and functional testing
2. Task ticket is ONLY responsible for application behaviour. It concerns only the dev team . It mainly pass through phases like developing and code review . It has its own target. Once it meets, it’s done. Here we are not talking about code changes but the application behaviour. The reason behind is another story. The main purpose is to reduce mistakes during your planning
3. The relationship between is Story ticket is blocked by Task tickets. The application behaviours in task tickets are supposed to complete the user story in Story ticket .
4. This splitting separates the life cycle of Story and Task. It makes the life cycle shorter and easier to manage. The time estimation can also be split.
5. A task ticket marked in build means the application behaviour will be there after the deployment.
6. A task ticket marked in build means the user story will be there after the deployment
7. Build testing should ensure expected behaviours in the build. Say, if Story A consist of Task B, C ,D. If only B is done and in build, the testing should make sure A doesn’t exist in the build and B doesn’t affect any expected behaviours
8. Code review should go before use case review and functional testing as we defined expected behavior in the Task ticket. The order of importance should be structural conrrectness > use case correctness
9. Reviewed PR can be merged directly. It avoids the problems of feature branch strategy.
10. If the finished work totally don’t fulfil the use case, we should review our communication process and also the planning instead
11. Cards are managing works but not code. PR should not be a must for a story ticket.

Operations

Normal flow

1. Product manager create a story ticket
2. Engineers estimate related application behaviour it should have to complete the use case and create related task tickets
3. Engineers complete a task and ask for review.
4. If it’s okay, merge the PR and put it into a build (mark in build )
5. Engineers complete those task tickets and do an integration. If things are good, ping Product manager for Use case review and QA for functional testing. update the story card to use case review phase
6. If the user story cannot be completed by the task tickets, we can consider add more task ticket until we complete the use case.
7. When task ticket is done, put it in a build and so is the story ticket

Kinds of story ticket

1. new user story
2. issue fix. it’s also a kind of user story change.

Kinds of task ticket

1. Backend new structure basic, like, new model or new service. The card will only provide the structure and, most of the time, provides no logic to handle use case
2. Backend behaviour change, like, validation rules change. if no code change, an integration test is still necessary as a prove
3. Backend API change. if no code change, an integration test is still necessary as a prove
4. Frontend shared library component
5. Frontend integrating the library component into an application as an application component
6. Frontend saga and reducer for an action.
7. Frontend new feature component
8. Integration

We do break down our task tickets into very small pieces. It benefits a lot.

1. small task means small PR. much easier to review.
2. small task give a very precise goal to each ticket
3. it ensure we plan before we work
4. tickets move fast
5. easy to track the progress of work
6. A user story can be highly distributed to engineers, not just divided by frontend and backend.
7. highly distributable work allow us to push a user story faster.
8. Team can work on stories one by one. Otherwise, review and testing can only be started just before sprint end

Conclusion

There are still lots of details in the flow, but the key concepts are here. We should also ensure code reviewing is the highest priority task for engineers. Every PR shouldn't stay for more than one day. For those stay, we also need to revise our planning process of tasks.

No solution can handle all situation. As a team lead, we should always review our work process to ensure things go smoothly and efficiently. And more importantly, it’s our responsibility to make everyone works happily.

Caution: This is a very subjective article.

Before reading this article, you may want to know more about HOW method and WHAT method.

https://medium.com/@tedchength/coding-how-method-and-what-method-d272067fef0

Unit testing is one of the important development steps. Every method in you program should be well unit-tested. When talking about unit testing, people always talk about high code coverage. Yet I do think we should also consider case coverage. Case coverage is even more important than code coverage. Having high code coverage and high case coverage, you just need to add a few more integration test.

However, some may say that having too many test cases is a kind of trouble. Every time you make changes, fixes and refactors, you need to update a lot of test cases. Even when you just finish a method, you may also find your new method is difficult to test. Unfortunately, you need to do a refactor and update your test cases.

But can we avoid this? I would like to share my experience. It’s also based on the concept ofHOW and WHAT .

Let’s think about a feature.

Feature
As an programmer, I order bubble tea under some conditions so that I can recharge myself

Given today is Thursday
When I think of bubble tea
Then I would make no order

Given I am in a hyper mood
When I think of bubble tea
Then I would make order by myself

blah... blah... blah...

And I try to make a class (not in a detail way)

Considering the orderBubbleTea method, there are lots of factors altering the return value. The return value changes under different situations and combinations of these factors.

factors: [
  'day', //line 4,
  'emotion', //line 6, 14
  'favoriteDrink', //line 8
  'tryNewDrink', //line 10
  'returnOfMakePhoneCall', //line 15
  'returnOfMakeOrder', //line 16
  'returnOfAskOthersToMakeOrders', //line 21
]

factorTypes: {
  day: ['thurs', 'other'],
  emotion: ['normal', 'hyper', 'other'],
  favoriteDrink: ['normal', 'null'],
  tryNewDrink: ['???'],
  returnOfMakePhoneCall: ['withMakeOrderMethod', 'withoutMakeOrderMethod'],
  returnOfMakeOrder: ['anything'],
  returnOfAskOthersToMakeOrders: ['anything'],
}

(I am not going to describe every assertion for the test. Just some points to note is that, for testing line 16-18 and line 21-23, we better assert the result should be what the method call (makeOrders, askOthersToMakeOrders) return with some mocking and faking. And for line 15-16, we can just assume, according to the code base, we can only handle cases that `makePhoneCall` will return a object with `makeOrders` interface. )

You may find there are too many factors to test and the tryNewDrink logic is too difficult to test. So, we do a refactor.

Obviously, the methods are easy to test now. They are now with limited factors and factor types. But this is not exactly what we want to do… We want to avoid this kind of refactor.

Lesson to learn

We better have a good plan before we code. Consider the above example.

What do you realize? Do you know what green part and red part represent ? They are actually HOW and What .

For those methods mixing HOW and WHAT , they are always difficult to test. If we can write our methods using the HOW and WHAT principle, clearly we can make our lives easier.

This is what I summarize for testing HOW method and WHAT method .

If you remember, a HOW method usually does calculations, algorithms and service calling. In this kind of cases, you want to test if the input and output are exactly match. For an easiest example, for a (a, b) => a + b , you may want to test with different sets of input and output to ensure the calculation is correct. (though we may need some other treatments to test those service calling method)

On the other hand, a WHAT method usually controls the flow . We need to test if methods are called with certain number of times or with that payload / if methods return that object returned by that method call. Lots of mocking and faking are required. We don’t care how that thing is, but that thing must be that thing. You can say it’s about the reference pointer.

Summary

If you have read these two articles, you can see the benefit of doing HOW and WHAT . It benefits our structuring, testing and planing. Case coverage should always be your big concern of testing. I created my tools to increase my test case coverage. You can check the link below. Actually this tool is deprecated, I created one rely on jest , but you can still have a look. You can find how I structure my test case to reduce the workload even I write a high case coverage test case.

https://www.npmjs.com/package/mocha-combo

Caution: This is a very subjective article.

I guess most of the programmers should have heard about Single Responsibility Principle . Yet, it may be a little bit abstract. That’s why I would like to simplify this with HOW method and WHAT method . Before moving on, please bare in mind that

HOW and WHAT are just a relative description. There is no fixed line to separate them.

HOW method

A HOW method is a method that describe HOW TO DO to archive a target. For example,

//example 1
function add(a, b) {
  return a + b
}

//example 2
function fibonacci(num) {  
  if (num <= 1) return 1;   
  return fibonacci(num - 1) + fibonacci(num - 2);
}

//example 3: transforming data structure
function transform(obj) {
  Object.keys(obj).reduce( (key) => {
    //some logic here
    return values.forEach( (value) => {
       //some logic here
    })
  }, {})
}

This kind of methods is more focusing on algorithms and calculations. They are the most fundamental components of the whole program. You may find them having operators and aggregating method calls. Besides, they may also call services , like connecting Database, calling AWS S3.

WHAT method

A WHAT method is a method that describe WHAT TO DO to archive a target. For example,

function orderPizza() {

  const whatToEat = pickFromMenu()
  const shop = makeCall('12345678')

  if (!shop) return null
  return shop.makeOrder(whatToEat)

}

This kind of methods is more focusing on flow and what steps to make to complete the task. They connect fundamental building blocks. You can find them heavily rely on calling other methods and calling iterating methods .

If you really understand the above things, you will realize the simplest example of how HOW and WHAT work together is the relationship between Controller and Model .

Controller and Model

Controller and Model are always only recognized as the components of MVC framework. Actually, simply by their naming, you should easily find that they are actually HOWand WHAT .

class UserController {

  //POST /users
  create(req, res) {
    try {
      const user = User.create()
      return user
    }catch(e) {
      return new ErrorResponse(e, 400)
    }
  }

}

class User {
  create() {
    //connect DB
    //insert record
    //return user or throw error
  }
}

The controller describes WHAT TO DO to handle the POST request. The model describes HOW TO DO to create a user record.

Delegate Pattern and Hooks

Understanding writing flow helps you make good use of Delegate Pattern and Hook.

ReactComponent

ReactComponent provides methods to fill. For example,

1. render() //return elements to display
2. componentDidMount() //extra things to do when the event happen

You don't need to implement when the render and componentDidMount to be called. You just need to manage these specific phases. If you think deeply, it's just the author of ReactComponent control the flow and WHAT TO DO of the whole DOM tree rendering flow.

iOS UITableView

UITableView *tableView = new UITableView()
tableView.datasource = (UITableViewDataSource *)datasource
tableView.delegate = (UITableViewDelegate *)delegate

//UITableViewDataSource interface
numberOfSectionsInTableView:
tableView:numberOfRowsInSection:

This is another example. The UITableView works with the UITableViewDataSource. They control the flow. Programmers fill in the HOW TO DO .

There are also lots of other examples, like the Directive of Angular.js, UIViewController of Objective-C, those Before/After hooks of those testing framework.

My experience

I built a messaging center for my team. It provides features like sending notifications and broadcasting messages. The messages should also reach multiple platforms.

I wrote a Class called MessageRequest which manage the whole flow of sending a message. It gathers information like the channels, endpoints of getting the list of the target audiences and the subscriptions of them. Yet, this class only control the flow. It never determine how to get the channel and subscriptions. These all are left to the delegates. So now, every new use case of sending messages, our engineers just need to do a fill-in-the-blanks. Since all these similar use cases are conforming to the same structure, duplicated code can be easily solved by subclassing or a deeper delegate patterns. Besides, due to the same reason, all test cases look very alike. In our implementation planning, we can easily foresee the whole outcome.

Summary

Understanding the above concepts help you to build a better code structure. I always use this methodology to build flows. Similar features can make use of the same flow. It ensures that you will always have ONE SOLUTION TO ONE QUESTION . Your implementation planning, test case writing and code reviewing will be way lot easier.

In next article, I will talk about how this HOW AND WHAT affect your unit testing. I guess it will give you a new insight. Thanks :)

I am going to talk about web automated testing. If you read the articles I wrote before, you would find that they were all about theory or even they were just experiment. Luckily, in the previous a quarter of a year, I have the chance to practice the whole thing.

“Once upon a time…”

The background of the whole was very common. A company did its QA testing manually and tried to make it automated. Nothing more. The result wasn’t that good. It was not scalable. It took lots of time to run once. Its learning curse was steep.

“Now…”

We have ways to aim at a 15-minute testing. (Actually, it can be faster depends on what you need. We will talk about the bottlenecks we have). And the whole things is easy to learn. Teammates can join the test development just after a half-day training.

Though there are still lots of problems to solve, as long as it’s scalable, it can be used in production, I think it’s already a kind of success.

If you are going to do W.A.T

The first thing you need to do is to let your boss know it’s never an easy to task to do. It involves different parties like devops, QAs and engineers (even better if you also get the product team). What I saw in different companies was it’s so hard to get these parties to work together. They have their own schedules. Probably they won’t want to invest a side-project with no guaranteed outcome.

My journey - How I start

the 1st Step

My first step wasn’t anything special. I just did a research on it. I picked Selenium, Docker, cucumber and Javascript. And in the end, I found I couldn’t skip Protractor and Jenkins.

1. Selenium — it’s the most common tool. It provide HTTP for you to work with. That’s mean there is no limitation on how you do your coding. It also provides an easy scaling solution. That’s the Selenium Grid.

2. Docker — the MVP of your whole setup, especially you are not a devops guy. How to install Selenium ? Docker. How to provide an easy setup development environment for QA? Docker. Docker, Docker and Docker. It helps a lot.

3. Cucumber — it is a framework that you can write Gherkin file (BDD). Some people will pick Jasmine, mocha or the others. Yet I do think mocha and Jasmine are too engineer-oriented about its syntax and structure. It’s so easy to foresee that most of the tests will be developed by QA. And also the power of a Gherkin file is far more than you can expect. I’m going to talk about this later.

4. Javascript — picking javascript is simple because it’s the most common programming language. Backend and Frontend developer both knows it. Programming newbies will also learn javascript first. (And I am a nodejs developer… ha)

5. Protractor — I had a misunderstanding about cucumber and protractor before. Eventually, I found that they are two layer things. The main purpose of using Protrctor is to do parallel test running. Protractor also claim that it support Angualar testing and also provides its own webdriver. I didn’t spend to much time on this. I just use it.

6. Jenkins — I just use it to link up the shell scripts. so we can just do things by clicking. Also, making Jenkins a starting point of test will make you test more stable and faster.

the 2nd Step

The second step was doing my own framework. I am not going into details.

1. some shell scripts — it makes difficult command easy
2. docker container of nodejs — teammates only need to install docker
3. docker-compose for a selenium hub — teammates can run their own server easily
4. Page object structure — Actually it’s a very common structure if you are using cucumber
5. HTML reporting.

6. Test Logs — logs are very important. Otherwise, test developers will need to see the test steps running in browsers for debugging

the 3rd step

Next, I did a “pitch deck”. I knew I needed to persuade different parties, including engineers, QAs, the product managers and, of course, my boss, to "invest" my new "product". I made sure my deck was easy to understand. Less words, more visual graphics. More equations of benefits, less imagination.

Of course, I couldn't make them all onto the boat. Yet at least we could start sailing.

My journey - crews

I separated work by 3 roles:

1. Engineer — handle all the coding stuff. provide new features of the framework. do code review.
2. Quality assurance engineer (QE)— do simple coding. make Gherkin file runnable test cases. run automated test for deployment
3. Quality assurance(QA) — write Gherkin file.

At this moment, I guess the best ratio of roles is 1:4:6. Yet I still don’t have a chance to give it a try. The key part is having good QEs. They know what the test cases are about. They know how to debug. They connect the programming things and the non-programming things. It’s also possible replacing QEs with Engineers, but it’s not cost-effective.

My journey — problems

Scaling the selenium server

The loading of the whole selenium grid should be measured accurately. Otherwise, you will get lots of timeouts during your testing. And many things will also cause you a timeout. It will be hard to debug, so I would suggest you really do a load test to ensure your gird provide enough resources.

Making use of docker, I was able to scale out the whole selenium server easily. Seleinum provides different kinds of Dockerfile. You can get the Selenium hub, the selenium node with chrome or other browsers. I just wrote a docker-compose file to manage the structure. After reading a few tutorials, my temporary setup is like this.

1. one C4.xlarge. It hosts the selenium hub and the Jenkins.
2. one C4.2xlarge. It hosts the selenium node with chrome which provide 30 sessions.

Remarks after some experiment:

1. selenium node consume quite a lot of memories.
2. selenium hub consume just a few memories and also CPU. You just need to ensure that’s enough network bandwidth
3. there are two factors of scaling. one is the number of instances of each selenium node. one is the number of selenium node. Some say you cannot just scale one of it. You need to find the magic balance of the scaling. Yet I have no efficient way to test it. I just scale the number of instances. (Since I use a large aws instance for the nodes. More nodes in the instance means more ports to open.)
4. I found that one c4.xlarge aws instance can support one selenium node with 8 sessions.
5. I found that my C4.xlarge only used about 3GB memory and under 5% CPU usage. (that’s why I also put the Jenkins in it)
6. Jenkins is a must if you really want to shorten your testing time. I tried to use my computer directly sending requests to the selenium grid in aws. There were lots of timeout when I scaled to a certain level.
7. Make sure you understand the maxInstance of protractor, max instance of selenium node and max sessions of selenium node. They are just like some gates. Every of them can be the bottleneck. What I found is the maxInstance of protractor means how many threads you want to start. max instance and max sessions of selenium node mean how many threads you want them to receive.
8. I am sure we will need another infra-structure for auto-scaling of selenium node. The current structure just fits our need.

Fixture setup

If you manage your fixture well, it will shorten your test time a lot.

Many of your test cases are going to create, read, update and delete your records. You can foresee that if your doing a parallel run with the same account, things will be very messy, even make test fail. There are also different kinds of accounts to setup. Some with these records inside, some with those records. That why we need lots of accounts. More importantly, you need a way to make sure you test case get the correct accounts.

I would like to split the question like this:

1. how to create test account efficiently

What we did is just create a “test case” including all the step for setup up an account. Of course we also some script to reduce the extra operations.

2. how to route the correct and available account to the test case

I wrote a ResourceManager class in my framework. It can will mark the account in use by writing a .tmp file and remove it when it become available again. Also, we have a config file storing the account with tags. By matching with the tag of each test case, the ResourceManager is able find a suitable account for the cases

Actually the ResourceManager is able to handle things other than accounts. You just need to give it a certain structure of data with tags. It will help you to manage it.

3. how to clean up the account after test

I added some roll back steps for each test case. If this test will create record A, I delete it in the roll back steps. I had read some articles. People are doing the same.

There are sill lots of minor things you need to handle. See if can write another short article on it.

Scaling test development

We really did try to add engineers to scale out the QE workers. The result was good enough. They just focused on handling the simple coding and verified the test case by some basic sense. If there were questions about the correctness of the test cases, they just ask the QA. But really, it’s not cost-effective.

Test deployment

It’s not good if you just rely on the automated test cases just after they were finish. Automated test is also a problem. It will go wrong. That’s why we adopted the normal development flow for application. We have master branch, staging branch and development branch.

The master is used for testing the application deployment. The staging branch is used for next release of test cases. We just make sure that the master branch and staging are always all passed.

We release new test cases every week. For every test case we release, we will still do the manual testing for almost 2 weeks. It’s just a simple double-entry method. After this period, we just rely on the automated test. You can also change criteria to “automated and manual test for 5 times” depends on what you need.

Summary

This article is just a brief summary. How the framework is like? How to really start a selenium grid with proper connections? Maybe we will also have other big problem later on. Just comments and leave questions. I will keep sharing my experience in this jounary.

You may like to read my old article about how I think about Docker, selenium and cucumber:
https://medium.com/@tedchength/web-automation-test-solutions-with-docker-selenium-and-cucumber-js-d01482786e6c

Objective: build a feasible web automation testing solutions that lower the learning curve of the whole setting up and coding.

Selenium Grid

Selenium helps you communicate and get elements from browsers. It receives HTTP requests and responses with the data you need. You can foresee that every programming language, that is able to send HTTP request, can communicate with Selenium

A Selenium grid consists of hubs and nodes. Hubs distribute works to nodes. Nodes receive orders and communicate with browsers. Obviously, it’s an architecture that you can do the scaling out easily.

node.js

Javascript is now a widely used language. AngularJS, ReactJS and node.js. And it’s easy to learn. That’s why I would like to use this.

Cucumber.js

Cucumber is a BDD test framework. You code test cases here. The most important advantage of it is the human readable syntax. Non-programmers can easily contribute to the code base.

Docker

Docker is now the famous tool that help setting up systems. With the help of DockerHub, lots of systems can be easily constructed by a few commands. This is the key part of the solution.

Situations

There are three situations (or problems to solve). Different solutions make us of different setups. They can be compared in the views of difficulty and scalability.

Quick Development

It’s the case that we are most likely to face. We have lots of QAs that know nothing about server setup. They just know some basic programming skills.

Our concerns:

1. installing libraries and servers is a difficult task
2. installing tools is kind of making your computer “dirty”
3. too many ways to install tools. there may be lots of differences among them.

my expect outcome:

1. QAs do not need to install too much tools, except docker and git.
2. QAs can use their own text editors to code
3. QAs don’t need to handle any server config
4. QAs can just destroy and recreate the system easily when facing weird issues

my solution:

1. QAs download code by git
2. QAs install docker
3. Developers config the whole docker-compose file. Actually, for Selenium Grid, you can easily copy the whole setting from internet.
4. QAs run ‘docker-compose up’ to start the whole selenium grid
5. the ‘docker-compose up’ will also start a node.js container to run javascript
6. with docker’s volume mounting, QAs can just edit code in the host computer.
7. with docker’s volume mounting, QAs don’t need to download application’s related packages. They all are installed inside the docker container.
8. QAs edit code in the host, and run test command inside the container.
9. DONE!

Problems left:

1. DockerHub doesn’t have the selenium-safari image. Safari cannot be tested.
2. As the browsers are inside the docker containers, you can’t see the browser running. ( Yet, when you literally start writing code, you won’t spend time on the browsers)

Deep-dive debugging

It’s the case that we will face the least. There should be cases that we really need to see the browser running (though I don’t even meet this situation, logically we need to plan it also). It’s exactly the opposite of the previous solution. I won’t spend too much time on this.

Our concerns:

1. sometime we need to find out how steps being run

my solution:

1. install the whole stack, git, node, selenium, all browsers…
2. do coding and run commands in the host computer

Problem left:

1. a lots… just the opposite of the previous solution

Regression test

Other than developing test cases, we always need to do regression tests before deploying.

Our concerns:

1. Regression test should involve Safari.
2. the host should be powerful enough to run these huge amounts of test cases as fast as possible

my solution:

1. as the setup will be a bit more complicated, we better setup a server to handle this. QAs can start the regression test by send HTTP request from their computer. Deployment tools, like Jenkins, can also run test on it.
2. using Docker compose to build a selenium grid like the quick-development solution.
3. also install one more selenium in the host. this selenium will handle all the Safari testing.

Whole Picture

To conclude, we can setup two regression test servers. One for Production, one for Development and QA environment. Based on the developer’s skill level, they can use the ‘Quick Development’ or ‘Deep-dive Debugging’ aproaches.

The remaining part !

The remaining part is the Cucumber layer. It’s a huge topic. I am still figuring it out. I have built a framework to some basic application management. Feel free to check this out:

Tedc0819/cucumber-web

It mainly handle the config massaging and page-object concept. Go and take a look of the README.md

In the last Article, I talked about how test cases benefit your development. Honestly, it was a boring article. In this article, I am going to talk about how I construct my test framework. Basically, it’s a framework based on mocha.

Objective:

Create a user-friendly test framework that:

1. only manage flow of the test
2. will generate test cases by setting
3. mainly handle Unit Test (the framework is just a generator, you can use it to handle integration test also)

Before talking about the design, there are a few things you need to understand. And I do believe they are the most basic principles of programming.

Always remember HOW, WHEN, WHERE, WHAT.

No matter which framework you use, for example, MVC, MVVM, React, you will realise that they are in everywhere. The most obvious example is MVC.

If you follow the ‘FAT MODEL, THIN CONTROLLER’, you will find that model is responsible of HOW to do. The controller is responsible of WHAT to do.

Let’s say you need to implement an API to apply a job. And users need to be authenticated before they can do so. You can immediately draft the methods:

1. Session.authenticate — it handles HOW to authenticate the user. It will do a query to see if a valid session record exist in Redis Server
2. AppliedJob.applyJob — it handles HOW to apply a job. It will create a AppliedJob record or return error after some checkings.
3. AppliedJobController.create — it handles the api request by controlling ‘WHEN to do WHAT’. It will call Session.authenticate to verify user and then AppliedJob.applyJob to complete what the actual API need to do.

Give up Flexibility and Gain Efficiency

Every time you refactor, you are actually reordering codes based on some assumptions or some goals to achieve. If you find that you code does not look ‘good’. Maybe it’s just you can’t defined your objectives well.

One of the example is React. Nowadays webpages become complicated and are with lots of interaction. People found that it was so difficult to trace the error in front-end development. They ASSUMED that the data flow was the main cause of the problem. Then set their GOALs to provide a unidirectional data flow. They were giving up flexibility of data flow to gain the efficiency of handling the architecture of the application.

Define roles, interfaces and layers

Every good framework defines roles, interfaces and layer very well. For example, most of the back-end frameworks consist of Router, Middleware, Controller, Model and Helper. If you are a back-end developer, you will understand it immediately when you hear their names. And you will say ‘when the client send a request, the router will route it to that controller and those models are going to do the stuff’. You won’t say ‘when the client send a request, it will be compared with a table to see where to go first, and then, that function will be call to generate blah.. blah.. blah…’. It is simply because people understand their roles.

Also, for React, it talks about Store, Reducer, Dispatch, Action and Prop. Store is defined to store the data. Reducer handle WHAT to do when actions are dispatched. Action is a well-defined struct. Their roles are clear. They are the core of React. Besides, ActionCreation is also created for centralising HOW the action is created. Somebody may even slightly redefine this component to also handle asynchronies dispatch. Yet it is another story. The key point is ‘Always remember what components are and which one is closer to the core part of the system’. By understanding the layers, you will know where to put the code handling business cases.

Assumptions

Most of the time, and obviously, a test case tests a certain point of a system, especially for unit test. The test logic flow like this ‘Under that FIXTURES, when I apply these ARGUMENTs, that POINT should give that RESULT’. Point to note is that a point does not mean to be a method. Also, arguments do not mean the arguments to the method, but to the test point.

When people try to test a point, they will think ‘ When I input a correct user id and a correct job id, the AppliedJob.applyJob should create a AppliedJob record and return that record.’ Unfortunately, when they literally implement the test case, they are actually thinking like this “When I input user id 113344 and job id 33, the AppliedJob.applyJob should create a AppliedJob record and return that record.’

Define interface for argument values using labels

To simplify, I will assume the test point now is just testing one method. Say, AppliedJob.applyJob(userId, jobId). For unit testing, we can easily plan that what cases will happen to userId and jobId.

For user Id:

1. correct user id that exists in the database
2. incorrect user id that does not exist in the database
3. maybe null will also be the input.

For job id, it should be similar.

1. correct job id that exists in the database
2. incorrect job id that does not exist in the database
3. maybe null will also be the input.

Actually you can foresee that we can construct a 2D array to indicate the cases. Let say they are called argumentType (argType). so let’s define:

//it’s good to have the same order to the method arguments
args = [‘userId’, ‘jobId’]

// according to the order above
argTypes: [
  ['correct', 'notExist', 'null'], //indicates the cases of userId
  ['correct', 'notExist', 'null']  //indicates the cases of jobId
]

//We can easily generate all the combinations
['correct', 'correct'] //means correct userId and correct jobId
['correct', 'notExist'] //means correct userId and wrong jobId
//blah blah blah ...

It’s going to be the key skeleton of the whole framework.

Mocha

Another key point of the framework is mocha. Our framework only helps generate mocha test cases. The mocha is still the core part. I am not going to talk too much on what mocha do, but more on how our framework targets to help the mocha test cases.

Mocha - the fun, simple, flexible JavaScript test framework

Before this framework, I tried to write my test cases like this to cover all the cases:

describe('AppliedJob.applyJob - (userId, jobId)', function() {

  describe('success - [correct, correct]', function() {

    it('should return an AppliedJob record', function() {
      // assert AppliedJob record
    });

  });

  describe('failure - [correct, notExist]', function() {

    it('should return Error blah blah blah...', function() {
      // assert error
    });

  });

  describe('failure - [correct, null]', function() {

    it('should return Error blah blah blah...', function() {
      // assert error
    });

  });

  // an all the other combinations

});

Now, with the combinations array, we can now do it like this:

describe('AppliedJob.applyJob - (userId, jobId)', function() {

  combinations.forEach(function(combination) {

    var isSuccess = shouldSuccess(combination);

    it("${isSuccess} - ${combination}", function() {

      //assertion based on combination

    })

  })

})

Of course, this is just code of the prove of concept. There is much more to handle, like phasing of mocha(e.g. afterEach, beforeEach). I am still working the tutorial and README of the framework. To keep track, please visit:

https://www.npmjs.com/package/mocha-combo

If you are really interested on this idea and can't wait for the tutorial, leave me a message here, I will try my best to help you.

Writing test cases has already become the most important part of my work flow. It was really a hard journary. I started this kind of test-driven develop for 3 projects. They were mainly backend applications. After spending lots of time on refactoring, refining my concepts about test case and presenting my ideas to my co-workers, I would like to share my thoughts and experience in this article. Maybe I will also write another article to talk about the framework that I wrote for testing and its design principle.

The workflow diagram

Everyone knows that things will be easy if there is a QA engineer in you team. Unfortunately, most of the time, there is only a QA team doing manual testing. Therefore, the above work flow is important.

Let’s say you are developing a system with test cases and assume your test cases can cover 50% cases of the features. After manual testing, your QA member discover 20% more cases. And you code these into test cases so that your test cases are now covering 70% of cases. You can also foresee that, with this kind of feedback loop, the test coverage will be in a trend of increasing.

Writing Test Cases don’t mean that QA do less work

I also struggled about how we should separate roles on these testing tasks. I would like to generalise it like this.

Engineers do cases that easy to foresee. QAs do the edge cases and the double-check.

It’s so obvious that the value of QA is to think and draft the test flow. They spend lots of the time to ask ‘what if ‘. “What if we don’t follow the flow and click another button?”, “What if we input blah… blah… blah…”. These ‘what if ‘ will finally become edge cases.

On the other hand, the value of engineers is to develop the application. Unlike the QAs, they have no time to ask too much ‘what if’. That why they just need to test cases that can be easily thought of. Practically, the cases tested by engineers, during the first phase of testing, are mainly based on the features’ acceptance criteria and also the combination of inputs.

Test Cases give you sustainable development

Existing features are safe when you and your teammates develop new ones.

Your teammates just need to run all the test cases before they push the code. If all the cases pass, everything will be safe. The test cases also help finding out issues if the cases fail.

Refactoring becomes easy.

With all test cases pass, it somehow implies that the whole project is in a stable state. As long as your test cases all pass, you can do any kind of refactoring. No matter how big your refactoring is, the test cases ensure that you application still fulfils all the existing acceptance criteria of features.

Sometimes you may also need to refactor your test cases. It’s also easy.

1. ensure all test cases pass.
2. Don’t make any further changes on the application code.
3. update your test cases.

Easy to understand, right? To be honest, this the most enjoyable advantage.

Test cases are lists of acceptance criteria and spec for features

Every test case exists for a reason. Everytime you run all the test cases, the result is kind of describing the current state of the application. “Under what scenario, with what kind of input, it should return what” or “What API should be able to paginate”

Applications can learn from failure

With the work flow stated above, your QA teammates help you to improve the coverage of your test cases. Your application can learn from new bugs.

Imagine if there is no test cases, everytime a new bug comes, you will just fix it. There will be no place to “jot down” the unexpected behaviour and also ensure it won’t happen again along the development.

Writing Test Cases can be efficient

I guess time is the biggest hurdle of writing test cases. Especially, you start this practice from your office work. You may need to convince you boss with the benefits it brings. And most of the time you teammates only care about how tight the schedule is. Yet.

You can never fly if you don’t keep trying.

To be honest, I worked over time for lots of days and kept refactoring the tests under different assumption. I definitly a huge investment. Yet I do believe that the final outcome will save me lots of time on moving cursor, clicking browsers or Postman and checking the result with my eyes. I can simply run the test to verify my work.

When I started working with test cases, I spent almost 90% on test cases and 10% on implementation. At that time, the test cases were just even the simplest ones. No matter how I refactor my code, the things just didn’t seem right. The efficiency didn’t seem improved much. The code wasn’t also look nice and easy to maintain.

I started another project. This time I tried not to refactor the code. Made every test case look seperated. Hoped that every teammate can contribute without understanding much about the structure. Of course, this was a stupid thought. Things still went worse as the project grew bigger.

Fortunately, I figured out what went wrong. What we need is a framework. I spent lots of time on thinking how it should be. And of course, after some experiment, it worked just right. Even my boss enjoy using my test framework. And they can easily code the test cases by following a few examples. Now we spent 60% time on test cases and 40% on implementation. Of course, the develop time is also shortened. I will write another article about the main idea of the test framework. Quite a lot to explain every decision I made. Maybe you can write your own in different languages.

Write Test Case, Engineers.

Basic (Continuous Integration?) Deployment with Ansible, Docker, Jenkins and Git

If you have read my last article, you will understand why I script my Docker Installation using Ansible.

For Ansible installation guide:

Installation - Ansible Documentation

In this tutorial, we are using:

1. Ansible 2.0.2
2. Docker 1.12.0
3. Ubuntu 14.04

Objectives:

1. Make the installation process repeatable
2. Make it easier for teammates to learn about the process

Folder Structure :

ansible:           //root of folder

  group_vars:      //storing variable according to different env
    develop.yml
    staging.yml
    production.yml

  inventories:     //grouping host according to env
    develop
    staging
    production

  roles:           //defining roles and their related tasks   

    common:        //handling common setting like: user setup
      tasks:
        main.yml
      templates:

    dockers:       //handling dockers installation.
      tasks:
        main.yml
      templates:
  
  deploy-docker.yml //the main playbook for the task 'deploy-docker'
  deploy-docker.sh  //shell script wrapping the corresponding .yml

the ‘docker-docker.sh’ is only my practice based on WHEN-WHAT-HOW-WHERE-to-do principle mentioned in last article. This practice make my Jenkins just need to know which script to run but know nothing about the parameters. Scroll to the top and read it for details.

Let assume we just want to deploy to develop environment.

inventories/develop:

[docker]
10.10.10.1
10.10.10.5
10.10.10.8

[develop:children]
docker

[develop:vars]
ansible_ssh_private_key_file=__YOUR_SSH_KEY_FILE_PATH__

Assuming we need three docker instances, we define the three IPs in the group named docker. Also, we define a group develop and state that docker is the sub group of develop. The [develop:children] is important. It tells Ansible that the hosts under docker belongs to develop and will use the group_vars stated in develop.yml.

group_vars/develop.yml:

---
//user account used to ssh the hosts
remote_user: ubuntu            

//non-sudo user to be created for running process
action_user: tedcheng

//password for the non-sudo user, actually we can have better way to not storing the password in code, but this is for simplifying the tutorial.

action_user_pw: __complicatedPW__

roles/common/tasks/main.yml :

---

- name: setup Action User
  user: generate_ssh_key=yes name={{action_user}} password={{action_user_pw | password_hash('sha512') }} shell=/bin/bash

Basically, the tasks in common should be simply creating a action user. The action user is for starting some process that you don’t what it to have too much access right of the system files.

Please beware that the password needed to be hashed. For more information, just google “ansible password_hash”

// if you need any proxy setup
---

- name: setup apt-get proxy
  file: path="{{apt_proxy_file}}" state=touch

- lineinfile: dest="{{apt_proxy_file}}" line="{{item}}"
  with_items:
  - 'Acquire::http::Proxy "__YOUR_PROXY_URL__";'
  - 'Acquire::https::Proxy "__YOUR_PROXY_URL__";'

- name: touch ~/.wgetrc and setup wget proxy
  file: path="~/.wgetrc" state=touch

- lineinfile: dest="~/.wgetrc" line="{{item}}"
  with_items:
  - "use_proxy=yes"
  - "http_proxy=__YOUR_PROXY_URL__"
  - "https_proxy=__YOUR_PROXY_URL__"

- name: setup Action User
  user: generate_ssh_key=yes name={{action_user}} password={{action_user_pw | password_hash('sha512') }} shell=/bin/bash

- name: touch ~/.wgetrc and setup wget proxy
  file: path="~/.wgetrc" state=touch
  become_user: "{{remote_user}}"

- lineinfile: dest="~/.wgetrc" line="{{item}}"
  with_items:
  - "use_proxy=yes"
  - "http_proxy=__YOUR_PROXY_URL__"
  - "https_proxy=__YOUR_PROXY_URL__"
  become_user: "{{remote_user}}"

In case your hosts’ network need a proxy server for connections outside the network, you may need to setup the proxy. This is my script for one of my project in production.

It setup proxy for:

1. apt-get
2. wget of the remote user (the sudo user)
3. wget of the action user (the non-sudo user for running application processes)

roles/docker/tasks/main.yml :

Actually I just turn the steps from the official website into Ansible script.

https://docs.docker.com/engine/installation/linux/ubuntulinux/

---
- name: install docker
  command: sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D

- name: add deb repo
  command: sudo touch /etc/apt/sources.list.d/docker.list

- lineinfile: dest="/etc/apt/sources.list.d/docker.list" line="{{item}}"
  with_items:
    - "deb https://apt.dockerproject.org/repo ubuntu-trusty main"

- name: apt update
  apt: update_cache=yes

- apt: name=docker-engine state=present

- name: add user mod
  command: sudo usermod -aG docker {{remote_user}}

- name: add user mod
  command: sudo usermod -aG docker {{action_user}}

The last two steps are required for let the two users access the docker engine.

// if you need any proxy setup

---
- name: install docker
  command: sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --keyserver-options http-proxy=__YOUR_PROXY_URL__ --recv-keys 58118E89F3A912897C070ADBF76221572C52609D

- name: add deb repo
  command: sudo touch /etc/apt/sources.list.d/docker.list

- lineinfile: dest="/etc/apt/sources.list.d/docker.list" line="{{item}}"
  with_items:
    - "deb https://apt.dockerproject.org/repo ubuntu-trusty main"

- name: apt update
  apt: update_cache=yes
  environment:
    http_proxy: __YOUR_PROXY_URL__
    https_proxy: __YOUR_PROXY_URL__

- apt: name=docker-engine state=present
  environment:
    http_proxy: __YOUR_PROXY_URL__
    https_proxy: __YOUR_PROXY_URL__

- lineinfile: dest="/etc/default/docker" line="{{item}}"
  with_items:
  - "export http_proxy=\"__YOUR_PROXY_URL__\""
  - "export https_proxy=\"__YOUR_PROXY_URL__\""

- name: add user mod
  command: sudo usermod -aG docker {{remote_user}}

- name: add user mod
  command: sudo usermod -aG docker {{action_user}}

This is also the setup for docker in case you need a proxy. One point to note is the “lineinfile: dest=”/etc/default/docker”. It enables the docker to download some public docker images through a proxy.

ansible/deploy-docker.yml:

---

- hosts: docker              // define 'docker' as our action target
  remote_user: "{{remote_user}}" //define user account for ssh login
  become: yes
  become_method: sudo
  serial: 1          //define the action will be done one by one
  roles:
  - role: common     //define 'common' role should be apply to hosts
  - role: docker     //define 'docker' role should be apply to hosts

ansible/deploy-docker.sh

ANSIBLE_HOST_KEY_CHECKING=false ansible-playbook main.yml -i inventories/develop

ANSIBLE_HOST_CHECKING is mainly for skipping the (yes/no) question of known_hosts checking for ssh

Finally, you can run

sh deploy-docker.sh

Recently, I tried to build a Continuous Integration (CI) deploy flow for my team. Then I start this study alone, and come up with these thoughts.

In the end, as we still didn’t finish all the test cases and we decided to skip it at this moment. It will be shameful if we call this deployment a CI flow. ANYWAY.

This article mainly provides the concept of the architecture. I won’t talk too much on how the precise steps being implemented.

Objectives:

1. Jenkins manages WHEN and WHAT to do.
2. Ansible manages HOW and WHERE to do.
3. Docker ISOLATE your application with the host, if the host can run docker, you can deploy your application.

What scenarios will be achieved:

1. Your teammates can help doing the deployment simply by clicking buttons using Jenkins.
2. Everything is scripted. Tasks will be repeatable and debug-able.
3. Deployment script will be put in the application directory and managed by git at the same time. This is a benefit if you are in a same time and doing application and system management at the same time.

4. of course there are much more …

Four main tools:

http://docs.ansible.com/ansible/intro.html#

To me, Ansible is the best tools for managing my deployment code, because:

You write commands to set the hosts’ states instead of running an action.

No more wasted time on writing if-else cases to check a file’s existence and delete it. The only thing you need to do is just state it as absent.

file: path="/etc/some_directory" state=absent

details: http://docs.ansible.com/ansible/file_module.html

You manage your hosts by grouping and defining roles

You can describe 10.100.222.1–10 are api-hosts. describe api-hosts need ~/.ssh/deploy.pem to ssh for deployment.

You can describe 10.100.222.11–13 are mongodb-replica-set. and 10.100.222.13 will be mongodb-backup-source.

These kind of grouping and making roles help you to seperate HOW and WHERE to do the task very well.

Docker is a tool that I love and hate it at the same time. The good things are:

Isolate the environment setup from the actual host machine by providing you a VM-like Docker container.

No matter what host machines your infra team gives you, you can deploy to these machines provided that they run Docker. Also, you can control what OS your application running in whatever the host machines are actually running

Deploy multiple applications on the same hosts thanks to the Docker containers.

It is always painful when you deploy multiple application on the same host machine. Image your have two sails projects, one is running nodejs:5.9.2 and the other is running nodejs: 6.0.0. It is will be a trouble the you need to config the node version for the two projects. Fortunately, with Docker container, you just need to specify the node version and installation in the separate Dockerfile. And the nodejs will be installed in separate containers. The host machine will just need to run the two containers and things are done.

Besides, for some macro service architecture, it will be much easier to setup if you need to run multiple services on the same host.

Large community provides different kinds of basic Dockerfile

There are lots of basic Dockerfile that you can start with writing your own, like nodejs and rails. Even you can just start a Jenkins server by using

docker run jenkins

The Docker engine will pull the required DockerImage and run the Jenkins.

However, there are down sides of using Docker. Yet, to be honest, when you are an experienced Docker user, you will solve these problems easily.

A large DockerImage will result in a slow export, import and shipping DockerImage among hosts.

The first thing you SHOULD KNOW about writing Dockerfile is how the DockerImage is actaully built from the Dockerfile you wrote.

One of the terrible thing is like this, in simple words, you write you Dockerfile command by command and each command will create a layer to record the actual system change by the command. For example, your first command delete 50MB files from the system. And then your second command add 30MB file to the system. The layers will treat it as a 80MB file change in total.

Of course, there are best practices to avoid this senarios.

Dockerfile should be well written in sequences to make well use of caches

Everytime you build a DockerImage, the Docker engine will cache the layers so that the building process will be faster next time.

One the example is that, for a nodejs project, it is always needed to install packages and also copy the application code into the DockerImage. These two actions both changes the result of the DockerImage and affect the caches. However, comparing the frequency of these two actions, you will find that running the installation of packages will affect the caches less.

A well-known tools manage tasks for servers. Actually, not much I can talk about Jenkins. It just easy to use and powerful.

Powerful plugins for hooking up the Jenkins and Github

For git users, it is a common task for you to hook up Jenkins and Github for deployment. Once you code changes in Github, your Jenkins get notified. Also, this kind of hooking is an essential parts of a Continuous Integration System.

GitHub plugin

Jenkins : GitHub Plugin

This one is what I am using.

Easy to setup slaves to scale your tasks in Jenkins

There are lots of cases that you need to create slaves for your Jenkins. for example,

1. There are lots of tasks to do. And you need more workers
2. There are some tasks require certain environment.

The first one is easy to understand. For the second one, for example, we need to deploy a DockerImage to some hosts when Jenkins noticed code is changed in Github. Where to pull the code? Where to build the DockerImage? In this case, you will need a Jenkins slave with Docker installed (it’s actually just a ubuntu installed Docker) to handle all the Docker related stuff.

( You can say that why not just install Docker in the Jenkins host. The main design concepts to me are:

ALWAYS MINIMISE THE NUMBER OF KINDS OF BUILDING UNIT IN YOUR SYSTEM.

DON’T MAKE YOUR BUILDING UNIT COMPLICATED.)

The plugin that help me a lot when setting up slaves is this:

SSH Slaves Plugin

SSH Slaves plugin - Jenkins - Jenkins Wiki

If you are already using Ansible, Docker and Jenkins, I am sure you know what is Git and what it helps.

Two Dimensions Deployment:

I try to separate deployment flow, in concept, into two dimensions, vertical and horizontal.

The vertical one focuses on how code change become a result of an application update in a server.

This dimension is solved mainly by:

1. the hook between Jenkins and Git
2. the Docker and Ansible slaves setup
3. Build, export, ship and import the DockerImage from Jenkins’ slave to the host by Ansible script.

The horizontal one focuses on how a group of hosts are updated.

This dimension is solved mainly by:

1. Jenkins tasks start an Ansible script.
2. Ansible ship and import the images in parallel
3. Ansible restart the Docker containers in servers one by one to minimise down time.

So Now…

Let’s try to talk about some real-life cases:

Assuming we are going to have API servers and Web servers and we are going to have a auto-deploying system (or Continuous Integration) in staging and dev and a click-to-deploy flow in production.

Our building units will be:

1. Docker Instances

Yeah, I can’t list more. Let see how we build with only Docker Instances.

Jenkins

1. Just run this in the Docker instance

docker run jenkins

2. Install plugins, hook GitHub and build slaves (maybe talk about it in another article)

Jenkins Slaves

1. With Docker installed, you just need to install Ansible in this instance.

$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible

API Server and Web Server

1. With Docker installed, nothing more you should do. Just leave the jobs to Ansible script to start a Docker container.

MongoDB

1. Just run this in the Docker instance

docker run mongo

(of course, you need to write a config file for replica-set, and mount volumes to store the data out of the Docker Container, but these can be scripted)

Redis

1. Just run this in the Docker instance

docker run redis

(of course, you need to write a config file for replica-set, and mount volumes to store the data out of the Docker Container, but these can be scripted)

The Evil Thing

If you are clear about this building concept, you will release that, except Jenkins requiring some unavoidable manual work:

1. every instance only need some standard command to do the extra setup and start its service.

2. With standard commands, things can be scripted.

3. With scripts, this architecture can be reproduced easily.

Also, as every basic building unit is a Docker instance, you can write a script to do it!

So everytime you need to scale out, you receive a new host / create a new host on cloud. Then you run script to install docker on it, add the IP to the correct inventories. DEPLOY!

In Jenkins

Jenkins only control WHEN and WHAT to do

We can create different cron job and task in Jenkins with only simple command to start the Ansible job.

(As there are always some variables when running the Ansible commands, I usually wrap it with a shell script stored in the code base)

In the Code Base:

Ansible control HOW and WHERE to do

For Ansible script, I mainly follow the official best practice.

LINK

1. You can see we separate variables and hosts IPs and groups according to different environments.
2. For roles, I usually name them with the tasks’ names. It seems more flexible. (any suggestions for this?)
3. The ***.yml at the bottom are the main playbooks to be run for different tasks.
4. The ***.sh is the wrapper for calling the Ansible command in order to simplify the script in Jenkins.

For Docker, you can see we have Dockerfile, Dockerfile_ecg. This how we try to handle different environments if needed.

We use Ansible to replace the Dockerfile with a suitable one before we build the DockerImage.

(If you still remember, what the Dockerfile build should be independent of the host machine. But for our cases, since one of the environment needs proxy to do connection and one of the cloud is going to be deprecated, that’s why)

Summary

I know this article may be hard to understand since I just talk about concept but not the whole implementation like other tutorials outside. Yet, to me, having a deep thought on how architecture should be made is the most interesting thing in engineering. Concepts also give you a structure to consolidate your knowledge and build your own stuff. Also, it will be a lot to talk about if we write these in step by step.

Feel free to give suggestions or ask questions.