Avis et détails du produit Shippable

C'est l'un des meilleurs sites web pour ceux qui réalisent un projet. Il est intégré avec GitHub. Tableau de bord personnalisable. Très facile de trouver quelque chose lié au projet. Docker est le meilleur. Je pense qu'il est préférable d'utiliser Docker parfois. Avis collecté par et hébergé sur G2.com.

Docker a certaines limitations qui devraient être supprimées. Le déploiement de projet prend parfois plus de temps que nécessaire. Il y a des bugs mineurs. Avis collecté par et hébergé sur G2.com.

C'est le meilleur service disponible pour les développeurs. Dockers est le meilleur produit. Il y a tellement de fonctionnalités disponibles dans Dockers. Il utilise moins de RAM. Il a des intégrations de divers dépôts comme GitHub et GitLab. Avis collecté par et hébergé sur G2.com.

Dockers n'est pas isolé comme les machines virtuelles. C'est un peu cher pour ceux qui sont débutants. Avis collecté par et hébergé sur G2.com.

Meilleur endroit pour les étudiants et les professionnels qui travaillent sur un projet. Nous pouvons explorer différents projets. Nous pouvons facilement déployer notre projet. L'intégration API est bonne. Avis collecté par et hébergé sur G2.com.

Le tableau de bord peut être amélioré. C'est un peu cher selon le besoin. Le déploiement prend plus de temps. L'interface graphique peut être améliorée. Avis collecté par et hébergé sur G2.com.

1. Construire sur votre propre hôte - Les développeurs peuvent configurer des conteneurs Docker sur leurs propres serveurs et y exécuter Shippable. Ainsi, vous n'avez pas besoin de stocker vos données sur des serveurs externes, offrant une meilleure sécurité et des économies.

2. Fichier de configuration pour décrire les builds - Les builds sont décrits dans le fichier shippable.yml situé à la racine de votre projet. Ainsi, c'est plus flexible et peut également être stocké dans votre dépôt de code car il s'agit simplement d'un fichier texte brut. C'est-à-dire que même le code de configuration peut être versionné et révisé plus tard. Si vous venez de Travis CI, Shippable lit directement votre fichier .travis.yml, vous pouvez donc l'essayer directement - c'est une fonctionnalité assez astucieuse.

3. Intégration Docker - Shippable est construit en utilisant Docker, un conteneur Linux populaire. Il a été initialement construit en utilisant son propre conteneur, mais lorsque cela a commencé à devenir trop complexe, ils sont passés à l'utilisation de Docker. Depuis le début, Shippable était différent des autres outils CI car, bien que Shippable utilise un conteneur (Docker), traditionnellement, les outils CI ont utilisé des machines virtuelles pour gérer leurs charges de travail. Fonctionner sur Docker signifie que créer et détruire des environnements de build est toujours un plaisir et qu'il n'y a aucune chance de résidu de la version précédente.

4. Il prend également en charge les tests contre plusieurs environnements d'exécution, versions et environnements, par exemple, différentes versions du langage, de la bibliothèque et du système d'exploitation. Ainsi, il vous permet de tester le code plus en profondeur dans de nombreux scénarios. Avis collecté par et hébergé sur G2.com.

Actuellement, Shippable ne permet pas de déployer nativement des artefacts de construction sur S3. Cela peut être contourné, cependant c'est un assez grand manque par rapport à Travis et devrait être corrigé à l'avenir. Bien que cela soit faisable avec un fichier de configuration, c'est plus difficile à réaliser. Avis collecté par et hébergé sur G2.com.

J'aime Shippable parce que c'est une solution tout-en-un pour nos besoins de construction, d'emballage et de déploiement. Il est facile de configurer le fichier .yml pour tester le projet à partir du code source, le construire et l'emballer en un binaire si les tests réussissent, puis le déployer automatiquement dans des environnements de test ou de production. Il permet de taguer automatiquement le package avec des informations de version et de stocker toutes les versions pour un accès futur et un retour en arrière.

Il est facile de le considérer simplement comme une solution de déploiement, mais il prend également en charge les rapports de test et un tableau de bord pour surveiller l'état des tests précédents et le changement de pourcentage de couverture. Cela aide à garder un œil rapide sur de nombreux projets sans avoir à entrer dans tous les projets et à analyser manuellement.

J'aime aussi qu'ils aient un gestionnaire de permissions administratives pour contrôler l'accès non autorisé de tiers que vous intégrez au projet. Les résultats des tests peuvent être rendus publics sans stocker les fichiers clés publiquement. Avis collecté par et hébergé sur G2.com.

Dans l'ensemble, je suis impressionné par le nombre de choses qu'ils ont ajoutées au fil du temps, mais j'aimerais avoir une intégration avec quelques services supplémentaires comme Heroku et DigitalOcean. C'est faisable avec SSH, mais une meilleure solution est préférable. Avis collecté par et hébergé sur G2.com.

Shippable offre aux développeurs la possibilité d'automatiser leur flux de travail, de la révision du code au déploiement en production, le tout sans écrire une seule ligne de code. Les scripts de construction et de déploiement doivent être écrits dans un fichier de configuration séparé qui est stocké avec les fichiers de code. Cela est bon pour la portabilité.

Shippable prend le relais dès qu'un développeur pousse du code dans un dépôt, gérant toutes les étapes nécessaires pour pousser le code en production. Tout est automatique et aucune interaction n'est nécessaire pour construire de nouvelles versions, tout est déclenché par le git push dans le dépôt de code.

Au cœur de la plateforme, elle offre aux développeurs un pipeline de livraison d'applications unifié, basé sur des conteneurs Docker, pour des systèmes de contrôle de source hétérogènes, ce qui la rend bien adaptée aux tests unitaires, aux tests fonctionnels pour ceux qui déploient des microservices, aux tests de résistance ou aux tests de sécurité. La plateforme prend également en charge les pipelines basés sur des scripts et sur une interface utilisateur. Les scripts sont plus configurables, tandis que les pipelines visuels sont meilleurs pour les cas plus simples et offrent plus de visibilité sur le processus pour tout le monde. Je préfère la deuxième approche pour la plupart de nos projets.

De plus, une fonctionnalité appelée Lighthouse permet aux utilisateurs de « s'abonner » à une image Docker et d'être informés de tout changement, quel que soit le gestionnaire. Si un changement est détecté, cela est à nouveau bon car les développeurs peuvent savoir que l'environnement de développement et non la base de code elle-même a changé. Les constructions déclenchées en raison de cela devraient alors être analysées séparément car il est plus probable qu'il s'agisse d'un problème avec les changements apportés à l'image Docker. Avis collecté par et hébergé sur G2.com.

Parce que c'est une solution basée sur Docker, les restrictions standard sur ces images s'appliquent toujours. Ainsi, il est souvent difficile de trouver les bibliothèques appropriées avec la version requise. Même alors, comme l'environnement est créé et détruit à chaque fois, cela prend un certain temps à chaque exécution pour créer l'environnement. Pour les solutions non basées sur Docker, il peut être mis en cache entre les exécutions, offrant un temps de démarrage plus rapide. Avis collecté par et hébergé sur G2.com.

Nous utilisons Shippable comme fournisseur d'intégration continue pour notre entreprise parce que nous aimons -

A. Échanger le fournisseur de VM avec Azure ou Google APP Engine - La VM par défaut fournie par Shippable est partagée par nature et inacceptable pour nous en termes de débit. Mais, la bonne chose est qu'ils prennent en charge l'utilisation d'autres fournisseurs de VM comme Amazon Web Services ou Google APP Engine en tant que backend. Nous utilisons un cluster AWS avec des tests parallèles pour réduire la durée de nos tests.

B. Axé sur Docker - Nous n'avons pas complètement migré vers Docker, mais nous testons un projet basé sur Docker pour un nouveau client et Shippable semble avoir un bon support pour Docker. Les hubs Docker, officiels et autres, sont pris en charge, leur approvisionnement en Docker est rapide et automatiquement géré. Les configurations Docker peuvent être fournies facilement via l'interface utilisateur, sans changer le code. Avis collecté par et hébergé sur G2.com.

1. Aucun support pour les anciens langages de programmation comme C++ et Java n'est fourni. Donc, nous choisissons Shippable uniquement pour les projets plus récents.

2. Aucun fournisseur de VM autonome - Nos serveurs personnalisés ne peuvent pas être utilisés avec Shippable car ils ne fournissent pas d'options d'auto-hébergement. Nous préférons les plans d'entreprise auto-hébergés en raison de notre large base de développeurs. Avis collecté par et hébergé sur G2.com.

Shippable est l'un des très rares serveurs CI qui ne supportent que les tests/déploiements basés sur Docker ou conteneurisés. Donc, si vous n'êtes pas dans ce public cible, vous n'avez pas de chance. Mais si vous utilisez Docker, Shippable offre un impact considérable et apporte une approche nouvelle au processus. Ce n'est pas très personnalisable, mais couvre beaucoup de terrain avec une intégration en un clic avec des services externes.

Choses que j'aime à propos de Shippable

=============================

1. Pipelines de livraison continue visuels - La méthode habituelle pour configurer le flux dans la plupart des serveurs CI est d'écrire du code bash pour toutes les parties du processus dans un seul fichier, mais Shippable est totalement à l'opposé. Vous avez une belle interface utilisateur de type chronologie où vous pouvez activer différentes cartouches de service comme des bases de données, des langages de programmation, des services de notification, le déploiement AWS, etc. Le flux entier est divisé en différentes parties comme CI, CD et notification.

2. Large gamme d'intégrations de déploiement - Supporte l'intégration directe avec AWS Elastic Beanstalk (EB), Heroku, Openshift, DigitalOcean et plus encore. Comme tout est spécifié visuellement dans le pipeline, ils doivent fournir des adaptateurs de déploiement pour de nombreux services et ils font un très bon travail à cet égard.

3. Supporte de nombreuses bases de données et langages dans le conteneur - Bien que Docker soit agréable pour exécuter tout séparément, son succès dépend de la modularité des images. Si beaucoup de choses doivent être installées au démarrage du conteneur, cela va être aussi lent que les VM traditionnelles. Donc, la plupart des bases de données et des langages sont modularisés en cartouches que vous pouvez activer de manière externe.

4. Tarification très abordable même pour les grandes organisations - Le compte de base est gratuit, mais les tests parallèles pour de nombreux conteneurs ou les déploiements multiples à partir du même pipeline coûtent 10 $ pour chaque élément supplémentaire. Même après 20 de chaque, le prix total s'élève à environ 400 $, ce qui est ultra bon marché compte tenu du volume de telles organisations.

5. Pipeline séparé pour les branches séparées dans les dépôts de code est supporté.

6. Connexion SSH pour le débogage des tests est très utile lorsque les bugs ne sont pas reproductibles sur les machines locales. Avis collecté par et hébergé sur G2.com.

Le plus gros problème est que leur segment de marché disponible est trop petit, car Docker n'est toujours pas si courant pour les tests dans la plupart des organisations. À sa décharge, il est très orienté Docker par choix et est assez bon pour ce segment de niche.

À part cela, certaines choses que je n'ai pas aimées à son sujet :

1. Support très limité pour les services de notification - Seuls Hipchat et Slack sont pris en charge. Un peu plus comme le support de Gitter, Email et IRC serait bien.

2. Exécution de tests lente pour les comptes de base - Les tests pour un projet de taille décente peuvent être très lents si les travailleurs parallèles ne sont pas utilisés.

3. Configuration via à la fois l'interface utilisateur (pipelines) et le fichier de configuration est un peu déroutante pour les débutants. Avis collecté par et hébergé sur G2.com.

Shippable est assez différent de la concurrence - c'est la première chose qui m'est venue à l'esprit en essayant de l'utiliser. Ils ont beaucoup innové pour séduire à la fois les développeurs individuels et les entreprises.

J'aime quelques aspects à son sujet :

A. Support multilingue avec un accent sur Docker - Shippable n'est ni une plateforme uniquement Docker ni une plateforme ignorante de Docker. Il détecte très rapidement le langage de programmation principal du projet, et si le projet est basé sur Docker, il récupère également les paramètres Docker et lance un conteneur pour le processus de déploiement. Il est assez facile de supposer à tort que Shippable est uniquement pour les projets Docker, mais ce n'est pas le cas - il s'intègre simplement très bien avec eux. Le support des langages est assez bon avec Python, Node.js et d'autres au menu.

B. Approche BYOH (Apportez votre propre hôte) - C'est là que le mariage entre les utilisateurs d'entreprise et les utilisateurs individuels entre en jeu - Si vous n'aimez pas les machines virtuelles par défaut fournies par Shippable comme plateforme de test et de construction, vous pouvez les échanger contre n'importe quelle instance Azure, DigitalOcean, Google App Engine, Google Compute Engine ou Heroku pour une expérience personnalisée. Vous pouvez également utiliser votre architecture sur site avec celles hébergées pour obtenir le meilleur des deux mondes. Les développeurs veulent utiliser les services populaires comme fournisseur de machines virtuelles et les entreprises veulent utiliser leurs propres machines pour la meilleure expérience.

C. Débogage - Un accès complet à la sortie de la console pour chaque test/construction et un accès SSH à ces machines aident vraiment au débogage lorsque les tests échouent pour une raison inconnue.

D. Auto-configuration à partir de fichiers de configuration de test populaires - Lors de la configuration, j'ai simplement activé la construction pour un projet sans rien configurer pour Shippable. Ce projet avait déjà Travis et Circle CI configurés pour des tests appropriés. Maintenant, je m'attendais raisonnablement à ce que cette construction échoue avec quelque chose comme "Aucun test trouvé", mais à ma surprise, il a reconnu l'un de ces fichiers de configuration et a exécuté toutes les commandes de test avec succès. Bien que les résultats des tests n'aient pas été collectés, ce fut dans l'ensemble une agréable surprise pour moi. Avis collecté par et hébergé sur G2.com.

Shippable est globalement assez agréable, mais je pense qu'il y a encore quelques petites lacunes qui doivent être abordées -

A. La VM par défaut était très lente à démarrer, prenant plus de 2 minutes. C'est assez lent par rapport à la concurrence.

B. Les bases de données et autres services sont difficiles à installer dans des environnements de test non dockerisés.

C. Toutes les parties des fichiers de configuration de test standard ne sont pas automatiquement reconnues par Shippable. Par exemple, apt-get <nom du paquet> n'est pas automatiquement détecté. Avis collecté par et hébergé sur G2.com.

J'aime la vitesse de construction car elle est basée sur Docker et son intégration de webhooks avec BitBucket pour le rapport de l'état de construction qui est publié par BitBucket sur Slack. Avis collecté par et hébergé sur G2.com.

Parfois, les constructions restent bloquées à l'étape de provisionnement du nœud et cela prend généralement beaucoup de temps pour terminer cette étape. Avis collecté par et hébergé sur G2.com.