As a programmer, you have to write code, and you have to write it every day. I have seen this expression in many places:
A programmer who can only write programs is not a good programmer
Of course, I don’t agree with this view, because some people are born for procedures. But it’s also a good idea to have some theoretical knowledge beyond code, which can take the quality of your code to a new level and greatly improve the efficiency of your code picking.
Recently, a new APP is about to be launched, but there are some problems in the aspects of product, research and development, and operation, which also make me calm down to think about some problems that are difficult for a programmer to face. Technology-related issues include:
-
APP version updates frequently.
-
Problems with inadequate test coverage.
The development of APP may be completely different from most of the enterprise application software, IaaS /PaaS platform and big data platform related products I have experienced before. In order to respond to market demand, the iteration cycle of APP should be in the unit of week (open the mobile phone and look at most commonly used apps updated every Week). IOS is also affected by Apple’s review cycle. There will be more uncontrollable factors. In order to solve these problems, the main work we are doing at present includes the following aspects:
-
Solve operational and product feedback mechanism issues.
-
Optimize the way apps are packaged and tested.
-
Make a reasonable release plan.
Today, I would like to share some basic knowledge of continuous integration and delivery/deployment (CI/CD) with technical staff, and discuss how to better optimize our product packaging and testing process by combining some problems encountered in the APP we are currently developing.
Continuous integration and continuous delivery/deployment of CI/CD
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
By integrating regularly, you can detect errors quickly, and locate them more easily.
The definition of CI above is based on thoughtWorks, which may be difficult to translate, but I can define CI as follows from the various CI tools I have seen over the years of product development:
CI (product) is a software development life cycle of the code quality, a continuous structure in the process of system integration, when as a team to develop products, everyone has to develop its function module, ultimately need to be integrated together, the code also need to be centralized managed in the same place, by using some automated code, packaging, testing tools, When developers submit code each time, the system will automatically package and unit test the program. If there is a problem, it will timely notify the relevant developers by email or other means.
Five years ago, I was engaged in the development of enterprise application software, then there is no unit tests, more no automatic packaging, testing tools, are you finish development function, to submit to SVN server, there is also a professional people in need to pack down the code down on their machines, packaging, and deployment to run a test environment, No big problem in the production environment. Think about it now or really “dirt”.
In recent years, my team and I have mainly developed an enterprise-level cloud management platform based on openstack. From ignorant at the beginning, we have formed a relatively mature development process based on CI, and we have also climbed over one pit after another.
At present, our relatively mature routine is: git+ Gerrit + Jenkins
Git is used for code hosting, Gerrit is mainly used for code review, and Jenkins is used for packaging and running unit tests. This combination of baidu, there will be a lot of ancestors have written a lot of blogs and articles, I will not waste energy here. What I want to introduce today is gitLab that we want to use in our APP development process. Otherwise, everyone will think that what I write is not dry, also embarrassed ah.
GitLab
GitLab is an open source application integrating code management, testing and code deployment. It includes a Git version management system with very good permission control, code review system, problem tracking system, activity feedback system, wiki, continuous integration CI system and so on.
The above translation may be a little awkward, but I can’t help it. Let’s get straight to the point.
My personal favorite is that GitLab looks a lot like Github, is easy to use, uses Github pull Request for code review, and has CI integration (although it mostly depends on how good you are at writing scripts).
I will use an ios demo project to show you how to use GitLab to manage code, review code, CI, and so on.
Install GitLab
If you are planning to use GitLab in the production environment, you can refer to the official installation documentation, including some cluster solutions can be found. Run gitlab with Docker on one command:
Assume that our server IP address is 47.88.21.77. Be sure to change the IP address according to your actual situation.
Sudo docker run --detach --hostname gitlab.example.com --env GITLAB_OMNIBUS_CONFIG="external_url 'http://47.88.21.77/'; gitlab_rails['lfs_enabled'] = true;" --publish 443:443 --publish 80:80 --publish 22:22 --name gitlab --restart always --volume /srv/gitlab/config:/etc/gitlab --volume /srv/gitlab/logs:/var/log/gitlab --volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latestCopy the code
After the service is started, the browser goes to http://47.88.21.77/
gitlab_login.png
For the first time, you can set the password of root and register the user to enter the system. Here, the user name used in the demonstration is CJZHAO. After login, the picture is as follows:
gitlab_firstpage.png
Empty…
Review code using GitLab
This is where you can create organizations and projects. The basic concept is the same as github. Here we create the project iOS_CI_demo directly.
gitlab_newproject.png
OK, many do not explain, a look to understand.
gitlab_projecthome.png
Creation is completed, enter the project home page, see the yellow tip information, in order to from a remote push the code to the server, need to configure an SSH public key, click add an SSH key add your public key is complete, you can upload the code to go up, the process does not capture the oh, see my public key is not very good… Ha ha.
After adding the public key, return to the home page of the project, as shown below:
gitlab_codeuploadmethod.png
We upload the existing code to GitLab using the third method, which executes the following code:
CD existing_folder git init git remote add origin [email protected]:cjzhao/ios_ci_demo. Git git add. Git commit git push -u origin masterCopy the code
Our app is very simple, as shown below:
Simulator_hello.png
It is obvious that Word is wrong, and we will show that another user submits the code after modification, and does the code review.
After uploading the code, enter the home page of the project, as shown below:
gitlab_project_home_first.png
Register a new user jack, then log in as cjzhao, go to the project Settings page (as shown below) and add jack to the project so that he can submit the code.
gitlab_project_setting_menu.png
Do your own research on the process of adding, it’s very simple, or the editor will think that my article just rely on screenshots. After adding, it will look like the picture below:
gitlab_add_user_to_project.png
OK, now modify the code with user Jack and submit it to git server.
Jack’s operation mainly includes the following steps:
Git clone [email protected]:cjzhao/ios_ci_demo. Git git checkout -b wordbug word to world" git push origin wordbugCopy the code
When Jack logs in to the system, he will see the submitted code and be prompted to create a Merge Request, as shown below:
gitlab_create_merge_request.png
Click Create Merge Request, fill in the description of the modification, and ask cjzhao to Merge the code into the master to submit.
After logging in to the system, YOU can see the branch that Jack requests to merge, as shown below:
gitlab_accept_merge_request.png
After the code review is complete, click Accept Merge Request to Merge the code into the Master. Select Remove Source Branch and Remove the WordBug branch.
OK, this completes the multi-developer project code review process.
The CI gitlab
Completing CI in GitLab involves two operations:
-
Configure a Runner(a server node for compiling, testing, and packaging).
-
Add the CI script file in YAML format to the project root directory. Gitlab-ci.yml.
The configuration of Runner
First of all, we will configure a Runner for our project. Since our project is ios, we need to compile and package our APP in an environment with macOS operating system and Xcode installed, so we need to configure a MAC computer as one of our Runners. The basic principle is to install a proxy program gitlab-Ci-multi-Runner on Mac, and then register Mac with GITLab server. Then, this Mac machine can receive CI tasks issued by GITLab server and complete corresponding compilation, testing, packaging and other work. The results are then fed back to the GitLab server.
To install gitlab-Ci-multi-Runner on a Mac, run the following command:
sudo curl --output /usr/local/bin/gitlab-ci-multi-runner https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-darwin-amd64 sudo chmod +x /usr/local/bin/gitlab-ci-multi-runnerCopy the code
Enter the Runner configuration page of the project, as shown below:
gitlab_config_runner.png
Execute the following command on your Mac machine to register this Mac with GitLab and bind it to our sample project.
gitlab-ci-multi-runner register #Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci): #Please enter the gitlab-ci token for this runner: #Please enter the gitlab-ci description for this runner: Mac_runner #Please enter the gitlab-ci tags for this runner (comma Separated): # Registering some tags, here we enter "MAC, Xcode7.1" # Registering Runner... succeeded runner=euasz2j9 #Please enter the executor: docker-ssh+machine, docker, docker-ssh, parallels, shell, ssh, virtualbox, docker+machine: # Here we enter shell, because we use scripts to compile, test, and package ios projects. #Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! Gitlab-ci-multi-runner install gitlab-ci-multi-runner install gitlab-ci-multi-runner startCopy the code
Now that our Mac machine is registered as a Runner, check out the Runner page of the project, as shown below:
gitlab_runner_running.png
Our Runner was successfully registered. Now you can script the CI.
Add CI script files.gitlab-ci.yml
Create a.gitlab-ci.yml file in the project root directory with the following contents:
stages:
- build
- archive
build_project:
stage: build
script:
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo clean
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo test -test-sdk iphonesimulator9.3
archive_project:
stage: archive
script:
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo archive -archivePath build/ioscidemo
- xcodebuild -exportArchive -exportFormat ipa -archivePath "build/ioscidemo.xcarchive" -exportPath "build/ioscidemo.ipa"
only:
- master
artifacts:
paths:
- build/ioscidemo.ipaCopy the code
The script above uses xctool, which is a facebook app packaging and testing tool to replace XcodeBuild. It is more log friendly and efficient. We need to install it on the Mac machine that installed Runner.
brew install xctoolCopy the code
OK, now it’s time to submit our latest code:
git add .
git commit -m "add CI cfg file"
git push origin masterCopy the code
If there are no exceptions, CI is already compiling, testing, packaging, and so on. See the following figure:
gitlab_project_build_status.png
See the passed in green? This means that the compilation, testing, and packaging all worked (it took me a long time to do this, and there were always problems). So I’m going to leave you there, and just to give you a little bit of a CD idea, now that we’ve packaged our app, we can create a branch of Releases, which adds a script for uploading our app to itunesConnect, This will allow you to complete the entire APP release process when a new version is released.
Apple provides a command line tool called Altool that can upload ipA directly to itunesConnect. For more information, see uploading your application binaries using Altool
OK, it’s really over. Go research yourself.
I hope you found this article helpful. Thank you.
CJ Recommended: Editor for Programmers -VIM(Love is Love) Contribute your code to the Open Source community Blog on Github What is DevOps? Js dependency management tool Bower JS modular programming – requireJS