I have several different agile boards for different products we are creating. In the dropdown list of sprints I see all sprints for all agile boards. Is there a way to filter the sprints to show only the ones applicable for that board?
Looks like Fix version field's bundle is shared between all the projects.
So when you create a board for project A you also see sprints (versions) you admit in another board created for project B.
You can check this assumption if refer to Administration-> Custom fields-> Fix version.
To fix this, create a copy of the bundle for one of the projects. Either from Agile board settings-> Create copy option in Board columns section OR from Projects -> Project A -> Fields -> Fix version -> Create independent copy.
Related
I use a long time EA for modelling. But i never found a suitable solution for following problem.
We develop products for customers in a very hierarchical way. Shared components (HW/SW/processes/...) are very similar.
We would like to have for each Application (Customer Project) a dedicated Project in EA. But this will use Elements of a Internal Library (Sub-Project), which is shared and should be aligned to all Projects.
Projectvariants:
Project 1 / Customer A
Project 2 / Customer A
Project 3 / Customer B
Project 4 / Customer B
Project 5 / Customer C
possible solutions:
one big project
each project with shared sub-project / library
each project with fake elements (manual deferencing LIB_HW_USB_HOST_2.3 )
one big project:
One Solution could be, doing all projects in one project file. This will be huge, because each customer and each project of a customer would be inside. But simple. All is in one. But everybody sees everything. Complicated Security model.
each project with shared sub projects:
Project Structure
The other way would be, make simple clear customer project based models, which will reference to the (sub-Project / library) and use these common elements from there, to illustrate some more detailed views. If using elements from the lib just drag and drop and get the detailed information, which are already written.
Fake elements
Third solution could be to create Fake-Elements LIB_HW_USB_HOST_2.3, but you have to look "manually" in the (Sub-Project / Library Project), and the direct linked infos (description, version,type) would be broken. Also clean simple models, which are showing only the necessary.
I would prefer the second solution, because the model is smaller. But i have no concrete idea how to solve this.
I love the JetBrains tools. But, I can't find a way to effectively share settings at the IDE level and the project level with team members. To date, I've followed instructions provided by an article on the JetBrains site, titled "How to manage projects under Version Control Systems". But, many comments on the article warn against implementing it as a method for sharing project settings. And I've run into a few issue with the method, namely not everything I'd like to be shared, is actually shared with team members.
I've also tried using the function found under the File->Settings Repository menu of the JetBrains tools. It shares some settings between users, and I like that it automatically creates commits to the Git repo, but it doesn't share all the settings. The settings that are shared work great! But, it seems like the "Settings Repository" feature is a work in progress.
I've read many discussions on this topic, but no definitive answer on a way to share IDE level settings and, at the same time, project specific settings when using the JetBrains tools. Not to mention, I use a multiple JetBrains tools (PhpStorm, PyCharm, WebStorm and IntelliJ). I'd like it if there were a solution that also shared settings between all the tools, because some settings are global across all JetBrains tools, some are specific to a particular tool, and some are specific to a project.
Sharing settings between JetBrains tools is more of a "nice to have". What I really need to know is, how can I share global IDE settings and project level settings easily between team members. But, I'll give mad respect points to anyone who can figure out both. :-)
I finally found a few minutes to write up an answer to this. I want to write up a more complete answer, but I've been incredibly busy lately so this will have to do for now.
This solution describes what I've been using to share code and settings of PyCharm projects. There is one caveat to this solution, which I'll attempt to describe and detail a work-around for.
Following the instructions on JetBrain's knowledge-base, we'll add the entire project folder to a Git repo. But, before doing so, be sure to exclude at least the workspace.xml file by creating a .gitignore file in the project directory and add at least the following line:
.idea/workspace.xml
# JetBrains also recommends adding tasks.xml, but I found it useful to
# share tasks with team members.
# Uncomment the following line to avoid sharing tasks with team members
# .idea/tasks.xml
You'll definitely want to add workspace.xml to .gitignore because it stores all of your local window sizes, debug panel layouts and the like. My team found it useful to syncronize our tasks, so that we could coordinate work. But, every team works differently, so use your own discretion.
There are three main locations project and personal preferences are stored:
<project_directory>/.idea contains project specific settings.
$HOME/.PyCharmYYYY.M/config contains options for all projects managed by PyCharm (or substitue "PyCharm" for any other JetBrains tool).
If you use the shared settings found in File->Settings Repository, $HOME/.PyCharmYYY.M/config will contain all of the settings shared via JetBrain's built in "shared settings" function. I and my team didn't care for it, because it seemed to automatically share some things we didn't want to (like the color theme, and key mappings). And we weren't able to select a sub-set of options to share team-wide. Long story short, it didn't give us the flexibility and control we need.
We did try using options 1 and 3 at the same time, but it was too unwieldy. For example, one person would change a font, and it would change it for the whole team the next time we re-launched JetBrains. It was a mess. If you do decide to try out using options 1 and 3, I recommend proceeding with extreme caution.
Presently, we are using only option 1, and it's working out quite nicely.
A few other notable folders you might want to add or remove from the .gitignore file are:
<project_folder>/.idea/runConfigurations/ contains all of your debug and run configurations used to run nose tests and debug into your code.
<project_folder>/.idea/scopes/ contains all of the scopes used to filter your view of the project files, into more management groupings.
$HOME/.PyCharmYYYY.M/options contains all of the global options for version of PyCharm you're using. For example, the color scheme, key mappings and any other non-project specific options. For a full list of other global settings, see this JetBrains article, or the following excerpt:
Greetings Stackoverflow Community,
I have taken on the task of 'unifying' 4 mobile iPhone apps that share 95% of the code and differ only in 5% (this is somewhat of an over-simplification, but never mind). Each of the apps has its own hefty set of resources (media files).
After 'unifying' the 4 apps, I will be adding new functionality to the apps, mostly functionality that the apps will share.
I would appreciate hearing your opinions on what's the best way to manage the code of these apps. Here is the approach I'm taking at the moment.
I'm maintaining only one Xcode project which includes the functionality of all 4 apps. The functionality that is not shared among all apps is enclosed in a condition such as: if (appName == 'X')...
Each app has its own info.plist file, so I have 4 of such files: infoX.plist, infoY.plist, ...
Before I build an app, two things are done:
a. in the Build Settings, I specify the name of info.plist to use.
b. I ensure that only the app's resources (media files) are in the project. I delete the other apps' resources.
As the apps are 95% similar in their code, having only "One App to Rule Them All" ensures that when the code gets upgraded, all apps enjoy the upgrade. You can assume that the apps will remain very similar in their code.
As the apps' media files are large and many, I'm keeping them off the Git repository.
How does this all sound?
Many thanks!
There are better ways:
A. Move to framework
It depends on how generic are common parts of the apps. But you should think about putting parts of it in a separate project that is a framework. You can link your 4 apps against that framework. But, of course, not everything will go there.
B. Have different targets
For sure you should have 4 different targets. Xcode let you set build settings for each setting commonly per project or specially per target. Additionally you can customize the build phases (including copy of the media files) on a per target base. So you do not have to rename or delete and insert anything. You simply select a target, you want to build.
C. Project tree
Xcode allows you to have subprojects with common code. Maybe things like common "foundation" classes of your app. You can have different projects for each app in a single workspace, all using the subproject.
Probably the best way is a combination, depending on what is the subject. However I would start with B. and likely add the other techniques, if needed.
I encountered more or less the same case, and we decided to use one Xcode project with multiple targets. That way you can simply change the target before hitting the build button (or configure specific build scripts changing the target). In our project, we had a few files sharing the same names (in different folders), and associated each one with a different target. For example, we had three "Stylesheet.h/.m" with different UIColor & UIFont definitions stored in different folders, and each one of them was linked to a different target. Same thing for the "Localizable.strings".
We're planning to launch a serie of applications in AppStore. They will be for some kind of different journals, showing different contents downloaded from a server via XML. So these applications will be made from exactly the same code (It's an universal application, so It'll work both in iPhone/iPad).
My initial idea was, in order to upload the application, compile just changing the images, logos and configurations (plist) that makes the application react as a particular journal. The compressed file would be uploaded to the AppStore.
However, this has resulted a horrible method, which promotes failures and mistakes. If I forget to change some image, as you can't see them in the compiled file (as it is included) they will end up in the store (and I will need four or five days in order to get the application changed).
I'm trying to look up for a better approach, wich keep the projects as independent as possible. I would like to be able to share the entire codebase: views, classes and nibs and create different projects for every journal.
Which is the best method to achieve that?. What structure would let me group both logic (controllers, classes) and UI and use it in the different projects?.
I hope I've explained.
As always, thank you very much.
You should keep most of your common code as a library project. Each final project should link with this project and provide images/assets along with code to mention these assets to common code. In my day job, I write a common library too, which gets used by 2 products/apps at my employer.
An Xcode project can have multiple Targets, all the Targets sharing code, but each Target getting its own resources (icons, images, text, plists, etc.) from a different subdirectory/folder within the same project directory/folder. Then you can check the whole thing, or just the shared source, into your source control repository.
You should also be testing each of your apps, built exactly the same way as any submission except for the codesigning, on a device before uploading to the store.
You can have a single Xcode project that creates multiple applications. You'll need to create a separate Info.plist with a different bundle identifier for each app.
If you are using a git repository you can just branch for each different app you want and that would keep track of all the differences and if you need to switch which you are working on you just have to checkout that branch. This would allow for the exact same structure just minor differences between the actual code for each.
I have a custom category ("disciplines") in my method plugin which I want to use to contain existing disciplines (from the Scrum plugin and EPF OpenUP library) as well as a few of my own (some are new, and others extend the OpenUP ones). I can add them simply, order them as desired, and view them in the Browsing Perspective and Preview tab.
However, when I publish, I cannot see the disciplines I have added or extended. There are no errors in the publish logs and the warnings I have refer to other things.
Your custom disciplines and extensions must contain tasks. When you add some, they will be visible upon publishing.