Shippable ist ziemlich anders als die Konkurrenz - das war das Erste, was mir in den Sinn kam, als ich versuchte, es zu nutzen. Sie haben viel innoviert, um sowohl einzelne Entwickler als auch Unternehmen zu begeistern. Mir gefallen ein paar Dinge daran: A. Mehrsprachige Unterstützung mit Docker-Fokus - Shippable ist weder eine reine Docker-Plattform noch eine Docker-unbewusste Plattform. Es erkennt die primäre Programmiersprache des Projekts sehr schnell, und wenn das Projekt auf Docker basiert, übernimmt es auch die Docker-Einstellungen und startet einen Container für den Bereitstellungsprozess. Es ist leicht, fälschlicherweise anzunehmen, dass Shippable nur für Docker-Projekte ist, aber das ist es nicht - es integriert sich nur sehr gut mit ihnen. Die Sprachunterstützung ist ziemlich gut mit Python, Node.js und anderen im Angebot. B. BYOH (Bring your own host) Ansatz - Hier kommt die Verbindung zwischen Unternehmen und Einzelbenutzern ins Spiel - Wenn Ihnen die von Shippable bereitgestellten Standard-VMs als Ihre Test- und Build-Plattform nicht gefallen, können Sie sie gegen jede Azure-, DigitalOcean-, Google App Engine-, Google Compute Engine- oder Heroku-Instanz für ein individuelles Erlebnis austauschen. Sie können auch Ihre lokale Architektur zusammen mit den gehosteten nutzen, um das Beste aus beiden Welten zu erhalten. Entwickler möchten die beliebten Dienste als VM-Anbieter nutzen und Unternehmen möchten ihre eigenen Maschinen für das beste Erlebnis verwenden. C. Debugging - Voller Zugriff auf die Konsolenausgabe für jeden Test/Build und SSH-Zugriff auf diese Maschinen helfen wirklich beim Debuggen, wenn die Tests aus unbekannten Gründen fehlschlagen. D. Automatische Konfiguration aus beliebten Testkonfigurationsdateien - Während der Einrichtung habe ich einfach den Build für ein Projekt aktiviert, ohne etwas für Shippable zu konfigurieren. Dieses Projekt hatte bereits Travis und Circle CI für ordnungsgemäße Tests eingerichtet. Nun erwartete ich vernünftigerweise, dass dieser Build mit etwas wie "Keine Tests gefunden" fehlschlagen würde, aber zu meiner Überraschung erkannte es eine dieser Konfigurationsdateien und führte alle Testbefehle erfolgreich aus. Obwohl die Testergebnisse nicht gesammelt wurden, war es insgesamt eine angenehme Überraschung für mich.

Shippable ist einer der wenigen CI-Server, die ausschließlich Docker-basierte oder containerisierte Tests/Bereitstellungen unterstützen. Wenn Sie also nicht zu dieser Zielgruppe gehören, haben Sie Pech. Aber wenn Sie Docker verwenden, bietet Shippable eine Menge und bringt einen frischen Ansatz in den Prozess. Es ist nicht sehr anpassbar, deckt aber mit der Ein-Klick-Integration mit externen Diensten viel ab. Dinge, die ich an Shippable mag ============================= 1. Visuelle Continuous Delivery Pipelines - Die übliche Methode zur Einrichtung des Ablaufs in den meisten CI-Servern besteht darin, Bash-Code für alle Teile des Prozesses in einer einzigen Datei zu schreiben, aber Shippable ist das genaue Gegenteil. Sie haben eine schöne, zeitleistenartige Benutzeroberfläche, in der Sie verschiedene Service-Kartuschen wie Datenbanken, Programmiersprachen, Benachrichtigungsdienste, AWS-Bereitstellung usw. aktivieren können. Der gesamte Ablauf ist in verschiedene Teile wie CI, CD und Benachrichtigung unterteilt. 2. Riesige Auswahl an Bereitstellungsintegrationen - Unterstützt die direkte Integration mit AWS Elastic Beanstalk (EB), Heroku, Openshift, DigitalOcean und mehr. Da alles visuell in der Pipeline angegeben ist, müssen sie Bereitstellungsadapter für viele Dienste bereitstellen, und das machen sie sehr gut. 3. Unterstützt viele Datenbanken und Sprachen innerhalb des Containers - Obwohl Docker gut ist, um alles separat auszuführen, hängt sein Erfolg davon ab, wie modular die Images gestaltet werden können. Wenn viele Dinge beim Start des Containers installiert werden müssen, wird es genauso langsam wie traditionelle VMs. Daher sind die meisten Datenbanken und Sprachen in Kartuschen modularisiert, die Sie extern aktivieren können. 4. Sehr erschwingliche Preise, selbst für große Organisationen - Das Basiskonto ist kostenlos, aber paralleles Testen für viele Container oder mehrere Bereitstellungen aus derselben Pipeline kostet 10 $ für jedes zusätzliche Element. Selbst nach 20 von jedem beläuft sich der Gesamtpreis auf etwa 400 $, was angesichts des Volumens solcher Organisationen extrem günstig ist. 5. Separate Pipeline für separate Zweige in Code-Repositories werden unterstützt. 6. SSH-Login für Test-Debugging ist sehr nützlich, wenn die Fehler auf lokalen Maschinen nicht reproduzierbar sind.

Integration mit Drittanbieter-Cloud-Plattformen wie Amazon EC2 Container Service (ECS), Google Container Engine (GKE) oder Red Hat OpenShift 3. Dies ermöglicht es Ihnen, einfach zu bauen und zu versenden.