I've started in this new company a few weeks ago, this is the CTO CI strategy:
Current: Developer team has the repo prod/master and they merge everything into master (no branching strategy). Once the code is ready in prod/master they'll ask Infrastructure team to start the deployment process which uses Jenkins.
The Infrastructure team executes a job in Jenkins that performs this actions:
- Clone the whole prod/master into build/master (so they don't mess with the developers)
- Execute scripts to build the binary(ies)
- Generate a .txt file with the version of the build
- Commit and push this changes into build/master (reason: prepare the deployment)
- Apply environment specific settings and push, configurations, binaries and code to distro/master
We end up with three repos at the end of the day for each application, that means, if we have 10 applications we would have 30 repositories
Reasons of the CTO for this:
- prod/master: For developers and their code (no branching, only master)
- build/master: For Infra team to generate versions (to prepare the deployment)
- distro/master: Binaries + code + specific environment configurations (to perform rollbacks, traceability and havebackup)
- Really complex process
- Unnecesary large data ammounts in repositories and slower processing when performing deployments
- Only works for FileSystem deployments (Databases are not considered in this sceneario and that kind of changes are manually performed)
- No instant feedback for developers
- Complexity when crossed patches/fixes and deployments
- Developers are involved in the production deployment (quite often, in order to test and apply changes on hot)
- Most of the deployments are performed directly into production
- There's backup and posibility to rollback
- Easy traceability (for rollbacks, not for development)
- Specific configurations per environment are stored in the repos with the code and binaries
And this is my approach:
- Developers create a JIRA ticket, which will be used as tag for the build and to create the branch
- Developers will deploy and test in a Q.A/PRE-PROD environment
- Once the code works, it will be integrated to master
- Once integrated with master, the binary goes to a "binary repo like artifactory or other"
- Traceability: The code deployed is easy to find through the tag (JIRA-XXX) for an specific build.
- Rollback: Taking the binary from the repo (Artifactory)
- One Repository per project, it means 10 projects are 10 repos, not 30.
- Instant feedback to developers, if the deployment is not sucessful they can change their code
- This design contemplates db scripts as hooks
- The configurations per environment will be handled with Ansible + GIT, generating templates with placeholders and a backup of each configuration.
- Re-educate developers to work in branches
- Force developers to integrate code only when it really works
- Change the CTO mindset only will happen through examples (working on it)
- We must create new infra (new environments to create deployments and not going to production directly)
- Lots of hours automating through hooks, rest apis
- Need to implement new technologies
I'd like to know the opinion of people with expertise on this git strategies and the balance between development and operations.