Good Workflows for the whole company
Last week, I met a start-up that is working on cloud software. Within their team, they have no one with a tech background. The development of their software is completely relying on two agencies.
One of their employees wanted to change some texts in their software. But he had no experience in software development, and his knowledge was limited to the names of the tools the agencies were using. So we sat together to introduce SourceTree, Bitbucket, VisualStudio Code and managed to get the text changes done, committed, and pushed. Naturally, my friend wanted to see the running software changes and not just in the source code. Did our text change produce some strange line breaks or container overflow?
At this point, we wished for a continuous delivery workflow. Even as a non-technical person, it is reasonably easy to do text changes when you know the power of a global search (mostly Shift+Ctrl+F) in your code editor. He could have created a pull request with a good workflow and see his chances in a test system just a few minutes later. Instead, we had to look at the readme file (which luckily was available) and understand how to start the project. The project was based on react and could work with a local or remote development backend. Several (brew, npm, and yarn) install commands later, and we arrived at the point where yarn start would produce an error message that we could not decrypt in the time that we had left…
The workflow that would make sense here is to trigger a build automatically whenever a pull request is created, or even every time something is pushed to the remote repository. Depending on the application, this could, for example, mean running a docker container or spawning a webserver on Heroku. To run a prepared application on Heroku whenever a change is pushed to Bitbucket, all that’s required is a file called bitbucket-pipelines.yml with the following content in the repository:
– git push
Unfortunately, it is currently not (yet) possible to run a pipeline only when opening a pull request.
The lack of continuous delivery meant that my friend could not see his changes in the running application. Still, he created a pull request and is now waiting for his agency to check his changes, deploy everything on the test system and notify him to have a look. In addition to this process taking a lot of time, the agency will also bill the time needed for this project.
We hope this post inspired you to work on your DevOps setup and play around with some integrations.
For more information about Bitbucket Pipelines and Heroku, check out: https://confluence.atlassian.com/bitbucket/deploy-to-heroku-872013667.html.
For more information on continuous security, visit our dedicated page.