How to Build Efficient CI/CD Pipelines for Startup Ops

Introduction

Continuous integration and deployment are essential challenges for every internet development team, especially for startups with rapid growth and limited technical accumulation. An efficient, sustainable operations environment requires solid standards.

1. Application Management Standards

1.1 Application Versioning

Use SVN or Git for version control; Git (e.g., GitLab) is recommended with a naming convention for groups based on product domain or front‑end/back‑end modules.

Example: http://www.maka.im belongs to the Git group official ; the store front‑end uses group store .

1.2 Project Naming Rules

All lowercase letters

Hyphens as separators

Pattern: [product]-[type]-[custom]

Example: official-store-customer

1.3 Branch Strategy

Common Git workflows:

Centralized workflow : single master branch, simple but limits Git advantages.

Feature branch workflow : develop on feature branches, merge via Merge Requests.

Gitflow : two main branches (master for releases, develop for integration) with feature, release, and hotfix branches.

Forking workflow : contributors fork the repository and submit pull requests; suitable for open‑source projects.

For small startup teams, a lean branching model similar to LeanCloud is often sufficient.

Current Branch Strategy Used

master : mainline for daily development baseline.

userA : developer A’s daily work branch.

release-201603091106 : created after integration testing for pre‑release.

hotfix-201603091106 : based on the release branch for bug fixes, merged back to master.

Developers rebase their feature branch onto the latest master to keep a closed loop.

3. Code Review

GitLab + Jenkins + Gerrit (the “three swords”).

Gerrit can be cumbersome for startups; GitLab Merge Requests or GitHub/Bitbucket Pull Requests are recommended. Phabricator is another option, though less friendly on Windows.

2. Permission Management Standards

2.1 System Permissions

Unified entry points, IP‑restricted access, no empty passwords, VPN‑only access to production servers via a jump host (e.g., Jumpserver). All operations are audited.

Production databases and Redis are isolated from the internet, accessed through phpMyAdmin or RedisLive with multi‑host controls and dangerous operations (e.g., DDL) blocked.

Development and testing environments have looser controls; leaders have both server and database access for debugging.

A staging node mirrors production for safe debugging without affecting live services.

2.2 Service‑Level Permissions

Web services run as www-data user/group; code directories owned by www, making them read‑only for the web service and preventing 777 permissions. Log and cache directories use www-data but block execution of PHP files.

Dangerous functions such as phpinfo, exec, eval, system should be disabled (see runtime guide ).

Open‑basedir restrictions should be enforced (see performance comparison ).

3. Configuration Change Standards

3.1 System Deployment

In traditional IDC environments, use custom images or Cobbler; register Puppet/Salt agents for automated service deployment.

In public clouds, create snapshots and images for elastic scaling.

3.2 Daily Changes

Daily changes (service or code configuration) are managed with Ansible, which avoids the need for agents unlike Puppet/Salt. All change files are version‑controlled with Git.

4. Release Policy Standards

4.1 Release Timing

Adjust releases to avoid business peak periods (except emergency bugs). Typical peak: 18:00‑23:30; off‑peak: 01:00‑06:00.

All releases must pass QA testing and product manager approval.

Lesson learned: unauthorized hot fixes can cause more severe production issues.

4.2 Release Tool Selection

Choose tools that solve real problems; avoid reinventing wheels. Popular open‑source CI/CD tools include Jenkins, Walle, Spinnaker, GitLab‑CI, Bamboo (commercial).

https://github.com/geekwolf/sa-scripts/blob/master/devops.md

Our automated deployment platform combines GitLab, Jenkins, and Ansible (Flamingo).

Flamingo ( https://github.com/geekwolf/flamingo ) is an Ansible‑based automated release tool inspired by Capistrano, supporting environment, host group, repository, branch, and project parameters, and can be repackaged.

Flamingo follows “rollback is release” principle; rolling back simply specifies the target branch.

Example command:

ansible-playbook deploy.yml \
--extra-vars='[email protected]:geekwolf/flamingo.git flamingo_product_name=flamingo'

5. Logging Operations Standards

Standardized logs greatly aid troubleshooting. For PHP, follow PSR‑3 format (timestamp, level, message). Use ELK stack to collect business logs, PHP error/slow logs, Nginx slow logs, and integrate with Zabbix for alerts.

http://www.php-config.org/psr/psr-3

6. Continuous Integration & Deployment Practice

Future articles will cover CI/CD practices for PHP, Java, front‑end, Android, and iOS.

Conclusion

This summary captures key CI/CD and operations challenges and offers practical guidelines for startups. While not exhaustive, it provides a solid foundation for building reliable, automated deployment pipelines.