CI / CD-Prozessaktualisierung: Vorbereitung und Planung

Klassische Einführung

1. CruiseControl.NET wurde als Build-System verwendet. Die Zusammenarbeit mit ihm ist im Prinzip ein zweifelhaftes Vergnügen. XML-Konfigurationen auf mehreren Bildschirmen, eine Reihe von Abhängigkeiten und Verknüpfungen von Konfigurationen untereinander, Mangel an modernen Lösungen für moderne Probleme.
2. Einige Entwickler (hauptsächlich Leads) des Projekts müssen Zugriff auf Build-Server haben, und manchmal möchten sie die ccnet-Konfigurationen ändern, die nicht geändert werden sollten. Ratet mal, was als nächstes passiert. Sie benötigen eine einfache und bequeme Verwaltung der Rechte im CI-System, ohne den Entwicklern den Zugriff auf den Server zu entziehen. Einfach gesagt, es gibt keine Textkonfiguration - es gibt keinen Ort, an dem man mit verspielten Händen klettern kann.
3. - … CCNET, git. (. ).
4. , . , . 
5. - , — ( ) .
6. . ? ? ? .
7. Suboptimaler Ressourceneinsatz und veralteter Prozess zum Erstellen und Bereitstellen von Code.

1. Einfache Wartung mit allen Konsequenzen (Backups, Updates, Problemlösung, falls vorhanden).
2. Universalität. Entwickeln Sie im Idealfall ein allgemeines Schema, nach dem alle Module zusammengebaut und geliefert werden, und verwenden Sie es als Vorlage.
3. Minimieren Sie die Zeit für das Hinzufügen neuer Build-Konfigurationen und die Wartung. Clients werden hinzugefügt / entfernt. Manchmal müssen neue Einstellungen vorgenommen werden. Es ist notwendig, dass beim Erstellen eines neuen Moduls keine Verzögerung bei der Konfiguration seiner Lieferung auftritt.

Vorbereitung: Repository-Konvertierung

1. Wir nehmen die Erweiterung mercurial hggit als Basis. 
2. Wir erhalten eine Liste aller Zweige des Quecksilber-Repositorys. 
3. Wir konvertieren Zweignamen (danke an mercurial und die Entwickler für die Leerzeichen in den Zweignamen, besonderer Dank für die Umlaute und andere Zeichen, die dem Leben Freude machen).
4. Erstellen Sie Lesezeichen (hg-Lesezeichen) und verschieben Sie sie in das Zwischen-Repository. Wozu? Weil Bitbucket und weil Sie kein Lesezeichen mit demselben Namen wie der Name des Zweigs erstellen können (z. B. Staging). 
5. Entfernen Sie im neuen (bereits git) Repository das Postfix aus dem Zweignamen und migrieren Sie hgignore nach gitignore. 
6. Zum Haupt-Repository verschieben.

1. $ cd /path/to/hg/repo
   $ cat << EOF >> ./.hg/hgrc
   [extensions]
   hggit=
   EOF
   

2. $ hg branches > ../branches
   

3. #!/usr/bin/env bash
   hgBranchList="./branches"
   sed -i 's/:.*//g' ${hgBranchList}
   symbolsToDelete=$(awk '{print $NF}' FS=" " ${hgBranchList} > sym_to_del.tmp)
    
   i=0
   while read hgBranch; do
     hgBranches[$i]=${hgBranch}
     i=$((i+1))
   done <${hgBranchList}
    
   i=0
   while read str; do
     strToDel[$i]=${str}
     i=$((i+1))
   done < ./sym_to_del.tmp
    
   for i in ${!strToDel[@]}
   do
     echo ${hgBranches[$i]} | sed "s/${strToDel[$i]}//" >> result.tmp
   done
    
   sed -i 's/[ \t]*$//' result.tmp
   sed 's/^/"/g' result.tmp > branches_hg
   sed -i 's/$/"/g' branches_hg
   sed 's/ /-/g' result.tmp > branches_git
   sed -i 's/-\/-/\//g' branches_git
   sed -i 's/-\//\//g' branches_git
   sed -i 's/\/-/\//g' branches_git
   sed -i 's/---/-/g' branches_git
   sed -i 's/--/-/g' branches_git
   rm sym_to_del.tmp
   rm result.tmp
   

4. #!/usr/bin/env bash
   gitBranchList="./branches_git"
   hgBranchList="./branches_hg"
   hgRepo="/repos/reponame"
    
   i=0
   while read hgBranch; do
     hgBranches[$i]=${hgBranch}
     i=$((i+1))
   done <${hgBranchList}
    
   i=0
   while read gitBranch; do
     gitBranches[$i]=${gitBranch}
     i=$((i+1))
   done <${gitBranchList}
    
   cd ${hgRepo}
   for i in ${!gitBranches[@]}
   do
     hg bookmark -r "${hgBranches[$i]}" "${gitBranches[$i]}-cnv"
   done
    
   hg push git+ssh://git@bitbucket.org:username/reponame-temp.git
   echo "Done."
   

5. #!/bin/bash
   # clone repo, run git branch -a, delete remotes/origin words to leave only branch names, delete -cnv postfix, delete default branch string because we can't delete it
   repo="/repos/repo"
   gitBranchList="./branches_git"
   defaultBranch="default-cnv"
   while read gitBranch; do   gitBranches[$i]=${gitBranch};   i=$((i+1)); done < $gitBranchList
   cd $repo
   for i in ${!gitBranches[@]}; do git checkout ${gitBranches[$i]}-cnv; done
   git checkout $defaultBranch
   for i in ${!gitBranches[@]}; do
       git branch -m ${gitBranches[$i]}-cnv ${gitBranches[$i]}
       git push origin :${gitBranches[$i]}-cnv ${gitBranches[$i]}
       git push origin -u ${gitBranches[$i]}
   done
   

6. #!/bin/bash
   # clone repo, run git branch -a, delete remotes/origin words to leave only branch names, delete -cnv postfix, delete default branch string because we can't delete it
   repo="/repos/repo"
   gitBranchList="./branches_git"
   defaultBranch="default"
   while read gitBranch; do   gitBranches[$i]=${gitBranch};   i=$((i+1)); done < $gitBranchList
   cd $repo
   for i in ${!gitBranches[@]}; do
       git checkout ${gitBranches[$i]}
       sed -i '1d' .hgignore
       mv .hgignore .gitignore
       git add .
       git commit -m "Migrated ignore file"
   done
   

Fazit

• Vorbereitung (Demo für den Kunden anhand eines Beispiels für einen Build, Softwareinstallation, Repository-Konvertierung, Aktualisierung vorhandener ccnet-Konfigurationen);
• CI / CD-Konfiguration für die Entwicklungsumgebung und ihre Tests (das alte System arbeitet weiterhin parallel);
• CI / CD-Einstellungen für die verbleibenden Umgebungen (parallel zu den vorhandenen "gut") und Tests;
• Migrationsentwickler, Staging und Test;
• Migrieren der Produktion und Übertragen von Domänen von alten IIS-Instanzen auf neue.