I have a Bitbucket project and it is designed in such a way, I have to create new repository as slide-project with copying base-framework-code(bfc) since each slide is unique in its own way(kind of animated learning slides) so utilizing the bfc to create a separate repo.
It looks like below - Solutions is project and it contains repositories(named as slides):
-> Solutions |
| -> Base-Framework-Code(bfc)(master)
| -> slide-01 |(master)
|src
|bfc
|package.json
| -> slide-02 |(develop)
|src
|bfc
|package.json
| -> slide-03 |(feature)
|src
|bfc
|package.json
My requirement is to implement TeamCity auto build feature in Solutions project itself.
When developers create a new slide-xx(a new repository), auto build should be triggered to that slide repo(for starters consider master).
Can I achieve this with TeamCity?
Please help with sharing any kind of resource.
PS. I'm new to TeamCity and still learning, I have gone through docs and demos and I know its working with specific repository with specific branches.
Thanks in Advance!
Related
We're planning a migration from AnthillPro to another build system.
As of right now, we're checking the option of migrating to Jenkins.
We have a lot of different Products, and each Product has it's own repository and it's own builds for every branch.
In AnthillPro, There are several layers:
Folders -> Projects -> Worfklows -> Jobs -> Steps
In Jenkins I so far only came across:
Views -> Jobs -> Steps
Is there a way to group the Views?
Or are there any methods to group the different components?
How would you implement the structure of:
Product -> Branch -> Builds
If each product have several branches, and on in each branch you need to run several type of jobs.
Currently you need to install some plugins to achieve this.
I would recommend the Team Views Plugin - it allows you to group jobs together and we use it heavily. There is also a Categories Jobs View plugin which I have not used but looks like it could provide a second level of grouping if needed.
There is also a "Folders" plugin that allows you to create jobs inside folders or folders inside folders:
https://wiki.jenkins.io/display/JENKINS/CloudBees+Folders+Plugin
We're working on getting better use out of our TFS/TFVC server and move to benefit from TFS Work Items, and I have been put in charge of figuring out how to do so.
We have a lot of projects, most of them working with common code libraries. Our way of implementing new features have been to just include a reference to the code and build it all together when changes are needed, instead of referencing DLLs for the libraries.
My question revolves around setting up workspaces that don't end up making this a hassle when updating code in common libraries as well as the main project being worked on.
In working with this briefly, I have created multiple team projects for each product we're developing and it looks like the individual developer has to make sure to move between all the workspaces connected to the individual project and check in code for each of them. I feel like this is clunky and that there must be a better way to get this done.
A structure could look similar to this:
ROOT
|- Common Code
|- Team projects (each having their own backlog and referencing "Common Code"
|--- Product one
|--- Product two
|--- Product three
Would a better approach be to work on a single workspace and just create teams and have backlogs for each or is there a clean way of allowing the developers to utilize a common code library from individual Team Projects?
There are a lot of considerations going into the setup of your team projects. The most important reason to separate out to different project is security. If you have a need to ensure that different projects can't see the metadata of other projects, then a single Team Project is a bad idea.
If your teams have major differences in the process they follow, they may also have a need for different Team Projects, as the Process can only be defined at the Project level and all teams under the same Team Project have to follow the same process (either Scrum, CMMI, Agile or a custom Process). It may be worth to move your teams to the same process template though, there are not too many differences between Scrum and Agile, so unless you depend on CMMI or a heavy custom template, you can practice Scrum and something other kind of Agile in either template with a little bit of fantasy.
In all other cases it may be valuable to consider creating a single Team Project and using Team Backlogs to represent your projects. This approach is commonly called the "One project to rule them all" setup.
As for your "common code" project, I'd personally consider using the Package Management features of Visual Studio Team Services to generate NuGet packages of changes made to common code. The ALM Rangers have written some guidance on setting this up in the past, it's not updated to the latest version of VS and TFS, but it does give a nice outline of the process. Then include these common libraries as NuGet package references to your other projects. This gives you more control over when specific projects upgrade to a specific version of the common libraries and it results in a nice separation between the different projects using the common libraries. After having done this, it's also easier to setup things like Continuous Integration, Gated Checkins etc. working with complex workspaces will make that harder as well as you'll find out.
So it'll look like:
+- YourAccount.visualstudio.com
+- CompanyProject (Team Project)
+- TFVC Repository (Can only be one)
+- Common (folder)
+- Project 1 (folder)
+- Project 2 (folder)
+- Project 3 (folder)
+- Package Management nuget repository
+- Common
+- Teams
+- Root / Company
+- Project 1
+- Project 2
+- Project 3
If you move your projects to Git, it also becomes a little easier, as you can have multiple Git Repositories under the same Project.
I'm newbie to TFS (2013). I used CVS in past, where we used to either create same Named Labels on multiple files or Branched labels to group files under one name, for specific tasks, like Marked with a build number, or Creating Patches/Hotfixes.
Now I'm looking for similar strategy in TFS.
Question: Is it possible to mark multiple folders/files with same Label?
Or
Question: Can we create a separate branch (with a particular name) upon multiple folders/Files?
Using any of above technique, I would be able to get multiple files, may be distributes among different folders, by specifying single Label/Name/Mark etc.
Any help would be really appreciated.
You can mark folders with labels via: Team Explorer (in VS) -> right click on folder -> Advanced -> Apply Label
You can branch in a similar way, TE -> right click -> branching and merging.
A good place to start would be to read the ALM Rangers' pdf on Branching Guide.
Our team works on a Agile methodology, having specialized teams in different parts of the product. Currently we have everything in a single Team Project, but we want to restructure everything so that we can apply a nice functional continuous build as right now, we have a build definition for our backoffice and one for our website. The problem is that if we make any change inside that team project, even if it's a text file, everything will go to queue and that is causing us big problems. So, this is how we would kill our problems:
# = Project Collection, > = Team Project, | = VS project
# PRODUCT
> Core
| CoreProject
> Integrations
| IntegrationsProject ( makes use of CoreProject )
> Backoffice
| BackofficeProject ( makes use of CoreProject and IntegrationsProduct)
> WebSite
| WebsiteProject ( makes use of CoreProject and IntegrationsProduct)
What this would allow us:
- Diminish the amount of builds in the queue
- Create branches of Integrations, which would not be changed often
- Restrict access to Integrations and Core to specialized teams ( even if i know this can be done in other way )
Questions:
Is this the possible best solution for our requirements? If not, what
would it be?
Let's say, working in WebsiteProject solution and having projects from diferent team projects in that solution, is it possible to checkin does projects?
Thanks!
I suggest having one big team project, and just have 4 root folders in version control, and 4 build definitions that have the workspaces mapped to each of the 4 root folders. So long as you have the build workspaces mapped appropriately, checking in files to one folder, won't trigger the builds for the other folders.
This also allows you to set separate security permissions on each root folder should you wish.
We would like to start using JIRA with GH for deployment/change management also. The proposed workflow for a Task/Story is as follows:
Backlog -> Open (added in the Sprint) -> In progress (coding) -> Resolved (code committed, work done) -> To Request for Change (Create a issue RFC-x which includes group of issues in the Sprint) ->
From here we track this RFC-x in new workflow:
In test system -> Being tested -> Verified by QA -> Approved by Management -> Deployed to Production -> Verified by end user
Is there a way to link group of issues in one Sprint or Version with an issue easily?
Using links is one approach
You can always link issues using the issue link feature provided by JIRA
http://confluence.atlassian.com/display/JIRA/Linking+Issues
There is a plugin which helps you track the links
https://studio.plugins.atlassian.com/wiki/display/ILR/JIRA+Issue+Links+Report+Plugin
or the links hierarchy report
https://plugins.atlassian.com/plugin/details/5003
You can even take it a notch higher by automating state transitions between issues.
We described the concept of separating specifications and tasks here: http://www.idalko.com/display/WIC/Separation+of+specifications+and+tasks
Another approach would be to include your RFC-x as part of the sprint, and group all the issues which are related using a fix Version.
The request for change allows you to track the status of the deployment, in the context of a certain version without the need to manage the links between the issues and the RFC.
For grouping issues, you might want to take a look at the Structure plugin - it's still in early Beta though. Would love to hear feedback and feature requests.
Igor