I remember when I was in school, the code was written and done. There was no process. Only now did I realize that getting online was not so easy.

preface

  • Go online need to prepare 📝 what
  • What should we pay attention to ⚠️
  • How to avoid online 🤔 problems

01 Preliminary Work

Recently, the concept of community group purchase is quite hot, and basically every Internet company will want to share a piece of the pie, and our company is no exception. Due to the urgent time and lack of manpower, our project is also rough. I think it does not meet the on-line standard.

But there was no other way. Since I accepted this project, I have been working continuously for more than half a month, basically without rest. Until this weekend, when it went live, it was a little bit idle.

Anyway, at least it’s online now. We can live with problems later.

But I want to tell you a little bit about the process of going online.

Machine + Domain name Application:

Applying for a server or domain name should be done early rather than at the last minute. One of the things to remember at the end of the day is that deploying the code is the real live, everything else is preparation.

Front-end interface dependency check:

The preparation revealed a lot of problems, among which I think the biggest one is that things in the formal environment are not ready for revision.

Because a lot of the time now we’re developing and testing code in a test environment, and then deploying the pre-release version when the test is done. There’s nothing wrong with either environment, because everyone pays attention.

However, merging interfaces into the Master branch presents a number of problems:

  • Code conflict
  • A lift online
  • Code depends on
  • Environment configuration
  • Dirty data

In fact, the above problems are only the main problems, in fact, we may have more problems than the above. A lot of times one person is going to do it, and the other person is not going to stay, so when you merge your code, you have a conflict and you don’t know how to resolve it.

Formal environment interface check:

In addition to making sure that the back-end code merges correctly, we also make sure that their interfaces are available. Just like this launch, after checking the back-end code is really no problem, the launch. But it turned out that some of their interfaces were not deployed to the gateway, so we couldn’t access them.

And my advice to you is that one of the things that we have to do before we go online is the online checklist.

Make a list of the environments, interfaces, and code you need to prepare, and then check them at the end. Not only check the regular data, we also check this launch special, such as jump to the third party links, etc..

02 Online Time

Time is also an important node.

But now we are going online for the first time, so our requirement for time is when we are ready. In addition, I recommend that you do not launch too late, according to our experience, after the launch, there will be a small problem that needs to be fixed. It’s a good thing no one’s using it, but if they’re using it it’s gonna have to be repaired urgently.

This time we started to prepare after 9pm, and then we went online for the first time after 10pm. Then, as expected, there were a few problems, and after some adjustments, the second wave of rollout began.

Not surprisingly, there’s still a problem.

There is no need to immediately understand the current problem (when no one is using it) when we encounter a problem. We should continue to check if there are any other problems, and solve them all at once, because going back and forth wastes more time.

After the launch, we still need to verify the complete process, which is also a time-consuming thing.

03 Avoiding Problems

The root of avoiding problems is that we need to prepare everything carefully.

In addition to some of the problems mentioned above that we should avoid, another important thing is to familiarize ourselves with the process of going live.

  • The code merge

Merging code in accordance with the development specification basically doesn’t have many conflicts, basically not. We want to make sure that the online branch is a clean branch.

  • Strict test

Coverage is one of the concerns of testing. We want the test to cover as much of the user’s operation as possible, so that even if we have a few minor problems, the main process can still run.

  • Code logic

If you want to avoid root causes, then our code is root causes. As long as there is no logical problem, then in fact our follow-up problems are not many.

As we now develop more, we basically know the bugs mentioned in the test. We should test ourselves during the development phase to make sure that process problems are avoided.