The difference between Buddy and other CI/CD tools is that you can seamlessly add it to your existing setup with dozens of integrations. Right now, each integration is assigned to an individual user. One of the imnprovements we are currently working on is the ability to share the integration with other workspace members. During the works, we decide to change the ID’s of the integrations from numerical to hash. This is important for users keeping pipeline configuration in YAML files as the ID defines which integration should be used in the action.
Numerical ID’s will be suported for two more months. From February 2020 onwards, adding new or modifying existing actions will require the new type of ID.
While lots of people think of CI/CD as something that lets developers deploy software faster and more frequently, let us not forget about its core principle: testing. Without testing, it is impossible to keep high standards of the code which constitutes the website. However, testing does not stop with deployment. Once our application is on the server, it should be constantly monitored for performance. Performance is one of the key factors that determine the position of the website in Google, the difference between life or death in online business.
For this, we can use Lighthouse, an open-source tool allowing developers to run performance audits on their websites. Buddy incorporates this tool as a dedicated action that you can use recurrently for round-the-clock coverage, or after every deployment to check the impact of changes on the website.
Obsessed with making CI/CD as easy as possible, in the past couple of years we delivered a series of actions allowing developers to automate application delivery in a couple in minutes rather than hours. However, Continuous Delivery is not limited to uploading files to the server. The essential part of the process is testing every commit and building the application before the deployment. Sometimes these steps require files which shouldn’t or cannot be stored in version control, such as configuration files or database dumps required to run tests.
A couple of weeks ago we released an update allowing users to manually set the timeout for individual actions. At the same time, the previous limit of 90 minutes (5400 seconds) remains the maximum execution time that can be set in an action. The only exception are notifications which are sent instantly. The feature is available in the Action tab: