Using Capistrano 3.4, is there a command to find the currently deployed version (branch and tag/revision)?
In the deployed root directory there is a file revisions.log. I could create a custom command to parse it, but especially in the case of a rollback, it's not very easy to parse:
Branch master (at 21) deployed as release 20151207160059 by Marco
Branch master (at 22) deployed as release 20151207180000 by Marco
Marco rolled back to release 20151207160059
In the release folder there is a file called REVISION which contains the VCS revision identifier that was deployed. You can simply cat that to get the revision.
Following on your initial thoughts, get the current revision (via https://stackoverflow.com/a/34156436/2832282) and use the revision.log file to find the matching branch name
revision_string = Rails.root.join('..', '..', 'revisions.log').readlines.detect { |rev| rev.includes?(revision_from_revision_file) }
"Branch production (at 6d68c9415e4d89a6c3119d68a164e50274a2e790) deployed as release 20190301085412 by Cyril"
and then
revision = revision_string.match(
/^Branch (?<branch>.+) \(at (?<hash>\w+)\) deployed as release (?<release>\w+)/
)
revision['branch'] # => 'production'
Related
I want to run TeamCity processes based on file existance.
I have two TeamCity processes (Dev and Prod):
Dev should be run if there is DevParam file in repo (or in specified location).
Prod should be run if there is ProdParam file.
I want to run exactly one process after each push to repository.
This files will be added and removed like:
[0] Repository has DevParam file
[1] Pushed, there is still DevParam file -> Dev process should be run
[2] Pushed, removed DevParam file and added ProdParam -> Prod process should be run
[3] Pushed, there is still ProdParam -> Prod should be run
I tried to create Trigger with rules, but I failed (rule like +:DevParam run also on file removal).
Git recognizes addind and removing this files as Moving with Rename, so it may be relevant.
file management is not a normal process. I strongly advise you to use the branch flow. For your example, use develop branch(DevParam) for an all your developers and master branch for a prod
Try to use the follows advice.
The developers are coding in the dev branch. Each developer working only this branch.
You should create the build configuration with the trigger to your dev branch. After each new commit, the configuration will be triggered.
If you decided that the code in the dev branch is ready to production, you just merged all to the master. And now you can also trigger the same configuration only for a master branch.
For more information about gitflow-workflow read this
I'm coming late to the DVCS party after developing solo for a long time by doing my own version control with copies of folders. For a small project, I would have essentially a folder structure that looked like this:
project
development
release1.0
release1.1 (for a bug fix)
release1.2 (for a bug fix)
release 2.0 (for a new feature)
I'm now getting on board and learning DVCS using Mercurial (SourceTree) and BitBucket, and slowly learning the ropes with both the GUI and command line with some new projects where I could start fresh using DVCS. I'd like to move some of my old projects into DVCS, but I don't want to lose my project history. What is the best path to follow, or is it even worth the effort?
I'm thinking something along the lines of the following (attempting to use an HgFlow methodolgy):
Create repository using code from release 1.0
Commit files into the development branch
Add tag for release1.0
Merge into the master
From the development branch, create feature/hotfix branch for release 1.1
Copy files from release 1.1 into hotfix branch and commit
Merge hotfix branch into develop and master
Add tag for release 1.1
From the development branch, create feature/hotfix branch for release 1.2
Copy files from release 1.2 into hotfix branch and commit
Merge hotfix branch into develop and master
Add tag for release 1.2
etc.
Does this seem like a workable approach? What suggestions do you have?
Yes, your approach is good. The only thing to add it to use hg addremove before you commit the next version of your code. This command can find renamed files for you and will thus help you recreate an even more accurate history.
The workflow then becomes
Create repository
Copy files from release1.0 into the working copy. They will all be seen as unknown (? ... lines in hg status).
Use hg addremove to schedule them all for addition. Adjust the .hgignore file to exclude build output before running hg addremove.
Commit and tag this as 1.0.
Delete all files from your working copy using your normal OS delete command. The files will now be listed as missing (! ... lines in hg status).
Copy files from the release1.1 into the working copy. Files that were changed compared to release1.0 now show up as modified and (importantly) newly added files show up as unknown while removed files still show up as missing.
Run hg addremove to schedule the new files for addition and the missing files for removal. If a file foo.c in 1.0 was renamed to bar.c in 1.1, foo.c will show up as missing and bar.c will show up as unknown. When you run hg addremove, Mercurial will recognize this as a rename. Use the --similarity option to adjust how similar the files need to be for them to be considered a rename.
Commit and tag this as 1.1.
Now repeat for the other releases. The important part is to clean the working copy between each code import — what way you make sure that each commit accurately reflects the state in the folders you used before.
I try to understand the right approach for managing hotfixes with TFS /source-control.
Say I have a small project to contains only two file (app.js and util.js). Both files are under source control (Team Foundation Server).
Assuming I applied two weeks ago a label that indicates the "milestone-1" that was deployed to the server. Since then I applied several other modifications (extended app.js and added another files).
Today I found a bug so I get the version with the label "milestone-1" from the server, modify the util.js and deploy this version to the server. The goal is that on the server only the version "milestone-1" including the hotfix-1 is deployed but not the modification I applied the last two weeks.
The question is: How /where do I check-in the hotfix to the TFS? Because I might find another bug tomorrow so I have to get the version "milestone-1" and the hotfix-1 base base for appling the second hotfix.
Is there a way to check-in a version of my code into the TFS that "sits" between label "milestone-1" and my latest version?
With branching and merging!
We have the following development cycle:
The initial project is created, permissions assigned, and imported in to TFS under branch name of "Main".
Because this is the initial iteration of development, we branch "Dev" from main, and that's where the developers work. Note at this point there is no official release.
When development is complete, it is merged back in to Main. No Dev work happens on the Main branch.
We branch "Release" from main, and that is the point at which the code is actually deployed, and version numbers are updated.
Ok, so, further down the line, we have to make some amendments. Once again, "Main" is branched out again and the development work continues down the Dev Branch. All is well. Then a user reports a bug that needs fixing, and it needs fixing fast. But we're half-way through our other development!! What to do?
At this point, we branch from main again. We'll call it "HotFix". The bug is fixed, and then HotFix is merged back in to main. We can then merge it in to our release branch, and the update is sent out. Our current dev work is not interrupted, and none of the work we have been doing up to this point exists on Main).
We finally finish our dev work, and we merge that back in to the main branch, and then in to release. Because our Hotfix branch got merged in to main, our new development work also contains the hotfix we did on the fly earlier.
You should use branching. Check out the "Rangers'" guidance.
I have successfully used the Advanced Branch Plan in the past, but you can customize it to your needs. You need to be disciplined with branching, merging, checking in, etc. Also consider shelvesets for code changes that aren't ready to be committed even to the DEV branch.
http://vsarbranchingguide.codeplex.com/
Let me know if you want more information.
We have a problem where despite no code changes SCM is triggering a build. SCM polls for changes every 15 minutes and should only trigger a build if changes are found.
Here are a few examples of consecutive SCM polling log.
Started on Nov 15, 2013 11:47:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.23 sec
Changes found
Started on Nov 15, 2013 11:17:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.22 sec
Changes found
Started on Nov 15, 2013 11:02:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.2 sec
Changes found
As you can see the revision is the same and matches that of
Git Build Data
Revision: 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 origin/develop
These jobs behaved as expected until a few days ago. There is nothing that we're aware that has changed about our environment to cause this.
I upgraded to the latest version of Jenkins (1.539) and installed plug-ins last night in a effort to resolve this but the behavior continues.
I just ran into Jenkins continuously building due to an SCM change, even when there was no change, and polling was not even turned on. This may be different from your scenario but I figured it may still help to share my solution.
Out project is configured to build using the branch specifier */integration just like all of our other integration builds. However, after looking at all of the branches on our origin git repo, I saw that there are two branches that matched the */integration specifier. It looks like a developer must have erroneously pushed to a new branch with a very similar name:
$git branch --remote | grep integration
origin/integration
origin/origin/integration
The solution that fixed this issue for me was to specify the branch fully, using refs/heads/integration. I assume it would also work to simply delete the duplicate offending branch, but by specifying the branch exactly I can avoid running into the same problem in the future.
I'm not sure this is the same cause for your problem but this is what worked for me, and hopefully will work for someone else in this situation.
Seems to be reproducible with latest Jenkins GIT plugin version 2.0.
Downgrade to version 1.x may fix the problem. Though you should also revert Jenkins configuration from older backup as GIT plugin version 1.x seems to be not working with new 2.0 configuration scheme.
This thread suggests to enable "Fast remote polling" as a workaround. In version 2.0 it's called "Force polling using workspace" I think.
Reference to Jenkins issue: https://issues.jenkins-ci.org/browse/JENKINS-20767
I was experiencing this same issue today. It started happening when I added the "Delete workspace when build is done" publish task. I removed that task and it seemed to resolve the issue.
I ran into the same problem.
What fixed it for me is noticing that the Git Polling Log looked like this:
Started on [date]
Using strategy: Default
[poll] Last Built Revision: Revision [commit#] (origin/develop)
[...]
Found 12 remote heads on ssh://[...]/repo.git
[poll] Latest remote head revision on refs/heads/feature/foo is: [commit#] - already built by 1414
[poll] Latest remote head revision on refs/heads/feature/bar is: [commit#] - already built by 2365
[poll] Latest remote head revision on refs/heads/feature/baz is: [commit#] - already built by 1489
[poll] Latest remote head revision on refs/heads/feature/qux is: [commit#] - already built by 1413
[poll] Latest remote head revision on refs/heads/develop is: [commit#] - already built by 2368
[poll] Latest remote head revision on refs/heads/master is: [commit#]
Done. Took 0.16 sec
Changes found
Notice that the line for master doesn't say 'already built'. I built the master branch and that fixed the problem.
Be carefull with svn redirections, in my case i had the same case Jenkins could not detect if svn has no changes and allways was triggering.
The problem was that in my jenkins svn configuration had this url:
https://xxxx.yyy.es:443/svn/myproject/trunk and its redirect to
http://xxxx.yyy.es:8008/svn/myproject/trunk (i dont know why)
Jenkins had to be configured with the last URL in order to detect the svn changes properly.
This is my issue Resolved.
http://antuansoft.blogspot.com.es/2014/10/jenkins-pool-smc-always-detect-changes.html
Removing the cleanup step at the end of the pipeline did the trick for me:
cleanup {
cleanWs()
}
There is another scenario in which this happens, which is if the repository was transferred.
I solved it by manually modifying the git URLs, which were inside the cache files (/caches directory in Jenkins home folder)
For a team of 4-5 developers using Visual Source Safe(VSS) 2005 what is best practice to maintain source versions?
Our requirement is to maintain and identify a version that is currently in production. This way at all times we will know what piece of code was pushed during deployment.
So far this is what I had in mind.
-trunk - Main solution and project
-Dev branches - branch created for development and enhancements
-Dev (some enhancement)
-Release - release branches
-Release 2.1.0
-Release 2.1.1
-Release 3.0
Everything that starts with a dash(-) above is a folder in the repository.
I am thinking that each time we need to make an enhancement to our project, we make a dev branch from the main trunk of the entire project. This will be where the developers will work on. Once development is complete and UAT is done we proceed to the deployment.
After the project(in this case a web application) is deployed and confirmed that it is stable we make a Release(version #) branch of the Dev branch above. Lets say this is Release 3.0, we now know that in July 2010 deployment we pushed the code in the Release 3.0 folder.
We then merge(is this easy in VSS2005) the Release 3.0 code with the trunk. This way the trunk is always the latest deployed code and the next enhancement will be branched from trunk.
HotFix
Some things that I have not yet figured out is what happens when there exists a Dev branch that is being worked on and there is a hot-fix that is needed to be deployed immediately.
Perhaps, we make a separate branch from the latest Release folder, call it Hot-fix 3.0. Have the developers make the fix, merge it with Release 3.0 code after deploying the hot-fix and then merge with trunk again.
Clean up
After release there is really no need to have the dev branches. Should these be deleted?
Since we are branching, I read that in VSS deleting a branch does not free up the space in the database unless the original is deleted.
How should we delete, or should we delete the dev branches?
These are my thoughts, how do you manage your versions and what are your recommendations for my requirements.
We MIGHT be moving to TFS in the future, so anything I implement now in VSS should consider this move in the future.
trunk -> should only contain stable code
tag -> add tags to the trunk code to identify versions (e.g. releases 2.1.0, 2.1.1, 3.0, etc.)
branch -> create a branch for every single issue
update -> update branches often to keep the code as close as possible to the trunk (because meanwhile other fixes where committed)
merge -> merge branches to trunk if the solution is stable (include the issue number so the code changes are related to the issue number)
Most important of all:
use a source control system which supports you in doing all this -> VSS will not ;)
Also take a lok at this interesting article: http://betterexplained.com/articles/a-visual-guide-to-version-control/