26 Mar 2020 · Semaphore News

    Visualizing the Deployment Pipeline

    2 min read
    Contents

    Today we’re rolling out a refresh of server pages on Semaphore. Servers define a deployment pipeline from your Git repository, going through a build on Semaphore to make sure all tests pass and finally to a deploy to your staging or production server(s). They also make it very easy to get an overview of how much you are shipping.

    New server page for continuous deployment on Semaphore

    In this redesign we focused on making the pipeline clear with three distinct elements: a commit, build and deploy. We tried to do that in the previous incarnation, but eventually realized that every line in the feed was composed in a way that is hard to grasp.

    Improved readability

    We also wanted to make the deploy history easier to read. We realized that in practice most of the builds that are being deployed originate from a “merge” commit. While Semaphore lets you write a custom deploy message in case of a manual deployment strategy, in case of fully automated continuous deployment this is currently not possible. And if you are using GitHub, that means that most of the deploy messages look something like this:

    > Merge pull request #1256 from renderedtext/ma/pray-that-branch-name-is-very-descriptive

    For this reason, deploy history now shows the first line below the merge information, as you can see for example in the “current deploy” block:

    Expanded current deploy message on Semaphore

    Start deploying from Semaphore

    If you are not deploying through Semaphore yet, now is a good time to start. It saves your team a lot of communication overhead as it is completely transparent what was deployed and when. The deployment process is one click away for the whole development team, which is very important if your goal is for developers to own their features completely.

    We have actually been deploying the main Semaphore web application continuously from master, and it has added relief, rather than stress to our workflow. In this case, every git push to master triggers a build, and if all tests pass the build automatically triggers a deploy.

    Note that if you are worried about everyone having deploy access, you can easily create an organization team with reduced access rights.

    We hope you like this change more than your average change of the Facebook feed. Feel free to let us know what you think, either in the comments below or the regular support channel.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Avatar
    Writen by:
    Marko Anastasov is a software engineer, author, and co-founder of Semaphore. He worked on building and scaling Semaphore from an idea to a cloud-based platform used by some of the world’s engineering teams.