I have to say that some portion of holy war is present here: when to bump a version. This creates the release, and pushes the release branch to server so the continious integration tool can pick it up and build it. Tar xvzf $current_artefact echo artefact unpacked: $current_artefact deployment/release_start.sh [ $ + | sort -r | head -n1)Įcho Working with artefact: $current_artefact # credits: http: ///questions/8653126/how-to-increment-version-number-in-a-shell-scriptĭeclare -i carry= 1 for (( -1 CNTR>= 0 CNTR-= 1 )) do ![]() The logic is simple enough - we read the current version from version.txt & apply shell magic to get next value. Thanks to the handy bash script credited in source, we can get the value of the next minor version via ➜ releasing. In most scenarios of continuous integration, subsequent releases changes only the minor version. I like idea with git tags in git-flow, but really would prefer to have the possibility to control versioning on my own. Simple text file, containing current project version. Let's take a look at the files' contents & purposes. As a result, typical devops magic structure looks like: |- build Thus, I usually have a deployment folder where devops scenarios live (usually I use an Ansible tool, although I had experience with CHEF deployments too), and suppose that developers will provide me with build logic that outputs target artifact files under buiild/folder. I support the idea that code infrastructure should be stored alongside the project code. ![]() ![]() Usually I introduce an approach with a set of file-helpers that migrate & evolve with each subsequent project. If you never heard about git-flow previously, I suggest you study the classic post ( ) & how Atlassian interprets the same idea ( ).įor those who already know git-flow, let me remind you of this well-known diagram: In this article, I will be using Atlassian Bamboo as an example. In this article, I will demonstrate one of approaches to introduce git-flow releasing into your project, and this git-flow can be integrated with the continuous integration tool of your choice. Perhaps most developers are familiar with the git-flow model that makes the release process controlled.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |