We are in the early stages of a relatively large development effort that will use Ext JS for its client user interface. The size of the team is not completely clear at the moment, but suffice it to say that there will be several developers working concurrently on building pieces of the UI.
The plan at the moment is to build many of the interface components following recommendations about using Sencha 'packages' and using Sencha Cmd to compile component packages into application pages. We also intend to setup Sonatype Nexus as a remote repository for compiled packages.
Where we are seeking guidance is in best practices on how to handle/setup development with a combination of multiple developers, source control and a remote package repository.
From other posts I've seen here, I gather that from a source control perspective people generally commit the workspace folder to source control (with the exception of the build folder and perhaps the Ext library itself). That means that source control has a workspace folder and the workspace folder contains a 'packages' folder that contains the source for each of the packages under development. This all makes sense to me.
Where I'm struggling is with the fact that the same 'packages' folder in the workspace is used for 2 things: it contains the source for packages that are under development and it is also the location where the source for shared packages is expanded. What you can end up with is a loop of sorts like this
I'm concerned about what troubles this could cause. A big concern is about developers losing uncommitted changes to a package if that same package gets overwritten by the source that gets pulled down from the remote repository. This would particularly be a concern if multiple developers are making changes to the same package. I've done some limited testing of scenarios, and it does appear that Sencha Cmd includes some safeguards to help protect the developer from this happening - at least when 'sencha app refresh' is executed.
- Code is edited in workspace\packages folder
- Developer commits change to source control
- Continuous integration or build server builds package and adds to remote repository
- Package is pulled from remote repository into local repository
- Package is expanded from the local repository into the workspace\packages folder (the same place where it started).
It looks to me like the app refresh command checks the version in the workspace\packages folder and compares to the desired version specified in app.json. If it's the same version, then the package is left alone. If the versions do not match, then the app refresh command generates a warning indicating that workspace\packages includes what may be another version. The warning is then followed by a NullPointerException which terminates the app refresh command. It will also terminate an 'app build' command as well - which could lead to a whole other set of issues.
I suppose in a way that's all good and provides at least some safety against losing changes. The developer can still overwrite their changes, though, by using 'sencha app refresh -packages' or 'sencha package extract'. The developer should also be able to get the build to complete by tweaking the versions in their local app.json file.
Q: Are other development teams just taking this as an acceptable risk (because it takes a little extra effort by the developer to make it happen) and relying on some proper instruction on what to do and what not to do? There is still the problem of actually building the application, though, which leads to my related question further below.
Q: Would it not make sense to have a way to distinguish which folder contains packages under development vs. those that were expanded from the package repository? I suppose one could take it upon themselves to move packages to a development folder (something like dev_packages) after using the 'sencha generate package' command and add that other folder to the application's classpath. I haven't tried that, though, so it'd not clear if the build process or generation of bootstrap.js would work properly.
Q: Is there a clear and clean way to separate development packages from those that come from the package repository?
A related question to this has do to with the build process. If you want to build the application with precise control over the versions of packages that the application uses, it seems like you need to make sure that the application only uses the expanded packages from the package repository. For example, suppose I'm building a new production release that uses version 220.127.116.11 of some package. At the same time, another developer has committed changes to the source repository that are targeted for version 18.104.22.168 of that package. I want to make sure that the application doesn't accidentally use the new code from source control - it should use the package from the package repository.
Q: How do people handle this (assuring that the app uses the proper versions of packages)? I think one way would be to have a second workspace in source control where only the application code is stored. Since pulling that workspace from source control would not pull any package source it would have to get all package source from the package repository. I'm also guessing that if one were to go this route for application builds, then there could be an application in the main/package workspace that does not specify package versions, causing it to just use whatever versions it gets from source control. Developers could then use that application for package development. Alternatively, I suppose one could include some other scripting in your build that removes the packages folder before building the application, thereby forcing the app build to download packages from the package repository.
Any specific advise as to how to manage developing packages and applications using source control and a package repository would be appreciated.