While going through the AngularJS phonecat tutorial (https://docs.angularjs.org/tutorial/step_00), I was very impressed the way the git repository is setup to allow the learner to checkout any particular step and look at diffs between that step and the previous/next step.
I started thinking about how the Git repository would be setup to achieve this.
Initially while creating the tutorial if each step was performed and checked-in and tagged then the repository would allow each step to be checkout and compared against other steps, easy. However, this quickly falls apart when you think the tutorial needs to be kept up-to-date without effecting the diffs between steps and also updating all the steps to use newer code or libraries.
Can some git ninja explain to me how they have achieved this. I see several branches and many check-ins to update to new version in their repo (https://github.com/angular/angular-phonecat). But the updates do not effect the learners view of the steps and the diffs between them. How?
I think the tutorial make use of tags to mark the commits in the project, you can type git tagand you will see a list of steps from step-0 to step-12.
you can make use of tags to mark your commits by using git tag [tag name] in your current working directory and the tag will point to your current commits.
Hope my explaination is clear enough that you can make use of it.
Btw The phonecat tutorial is really good.
Related
This question is more of an application architecture and source control type of question.
I have 2 Github repositories, one is a React single page application and the other is for a React website. For my single page application, I am making the code publicly available and the application links to its repository. For my website, I want to keep the repository private but incorporate the single page application into it so people can use it without having to download and build code.
Can I get some options on how to merge changes to the single page application repository with the website repository?
So far I am just merging code to the website manually by copying it over and pushing the code, but that is a problematic way of doing things. Neither repo is completely up and running yet, so there is still time for me to make architecture changes. Maybe there are git commands to handle everything?
Any help is appreciated, including suggested architecture/repo changes.
I think the best option here would be to use git cherry-pick, but in an automated way:
Build a simple script that listens for push events via git webhooks, from your single page repo. That way you can get the merge-in-master event automatically
Get the hash of that commit
Plug that hash into the git cherry-pick command applied on your private website repo. You can apply this commit on a separate branch in this repo, and merge it in master when you think it's appropriate
Does anyone experiment in creating salesforce Package.xml automatically for continuous integration? If there any script or some idea please share.
You know incremental package.xml helps to deploy only the modified files rather than using complete package.xml that redeploy unmodified files as well which takes a lot of time.
Thanks in advance!
Tricky. And not really a programming-related problem, consider cross-posting this to https://salesforce.stackexchange.com/ or maybe even https://devops.stackexchange.com/
I don't think there's no clear answer, you'll have to experiment. Especially that you tagged "migration tool" (so old-school, battle-tested but lower priority Metadata API; seems that all focus is now on SFDX style of deployments). Do you use any version control (ideally Git) or do you hope to somehow compare source & target org, figure out the deltas and deploy only them?
Remember that often SF gets better at detecting "no changes" with every release (how old is your migration tool's jar file?). For example when I deploy my current project to an empty sandbox (exact copy of prod, no custom objects, code etc yet) the initial deploy takes ~7 minutes. But any subsequent deploy with same content or slight changes takes just 3-4. So try to calculate time lost in the grand scheme of things and decide what gains you want to see / how much time you want to spend on experimenting and tweaking the solution.
You could look into dedicated deployment solutions such as Gearset, Autorabit, Odaseva (I'm not affiliated with either and this list is not exhaustive). They often are capable of running a comparison for you.
There are several projects that try to compose package.xml based on Git diff(erence) between two commits. Of course you need to have a repo first and some regime:
https://github.com/cloudsandbox/sfdx-gen-pack saw presentation about it at Cloudforce London 2019
https://github.com/Accenture/sfpowerkit seems to have a "diff" command (disclaimer: I used to work for Accenture but not affiliated now, haven't worked on the tool, haven't used it personally)
https://cumulusci.readthedocs.io/en/latest/ this seems to be interesting and mature. Built by SF employees, not an official tool but used to CI deploy the non-profit packages they build (maybe you heard about Non Profit Starter Pack, especially if you ever considered enabling Person Accounts). I'm not sure if they do delta deployments as such but there seems to be a command that updates package.xml with files in repository so it's a start? https://cumulusci.readthedocs.io/en/latest/tutorial.html#part-4-running-tasks
I'm not saying CumulusCI will be a silver bullet but out of these 3 seems to be most actively maintained ;) But sounds like you'd have to get familiar with SFDX (if not whole thing then at least commands to convert the project back and forth between "source" (SFDX) structure and Metadata API structure
Answering my question by myself: I found git diff master feature/vat | force-dev-tool changeset create vat working!
Thanks to Roman answered in https://salesforce.stackexchange.com/questions/184332/is-there-a-pre-build-solution-for-generating-a-package-xml-from-a-git-repo
Brand new to netlify/netlify-cms.
This is probably going to sound like a very stupid question. My team is very interested in using netlify for a website rewrite to replace WordPress.
However, there is one thing that I am stuck on understanding.
I'm hoping someone can help me wrap my head around it.
For this project, we would like to have multiple environments. For the sake of simplicity lets just say a staging environment and a production environment.
It's my understanding that by using different config.yml files for each environment, I can achieve having content from each environment site committed to the appropriate branch.
This leads me to where I'm struggling.
This staging environment is going to be used for testing.
Testers are going to throw whatever they need to in there to complete their test case.
For instance, to test blogging, they may create a completely fake blog entry. That will result in that entry being committed into the staging branch in git.
When we deem the new features ready to go live, I would want to merge the new features of the site up to production, but I certainly don't want to merge any of the testing content.
Being that those are committed to git, how can I PR changes from staging into production without also pulling the test content into production?
Turns out, pretty stupid question. Answer from the netlify gitter chat.
#jansselt you can use an additional branch, there's no limit there. Have your testers use a separate "testing" environment.
What is the decision tree to know when to split a suite of related and/or cohesive applications into git repo's and/or branches? Should I keep each app in a repo? Or all app's & dependencies in a single repo? Or something in-between?
answer How should I organize multiple related applications using git? claims that a repository per project is appropriate, but does not give clues as to what a project would be.
And then there's the question of dev, test, integration test, and production checkouts when the git repo's are split. Answer how do you organize your programming work lists some branch/tag options, but ignores the multi-app details.
There's also the DB schema! incremental definition of the schema helps, but again, where would one keep this definition if the DB spans back-end and front-end app's?
Some examples I've been pondering:
a front-end web app and it's back-end CGI/DB: one repo or two?
a set of web back-ends that use features from other back-ends
a set of front-end app's that share CSS and jquery plug-ins
selenium scripts that test front-end features across dependent code - in the front-end app repo or the dependent code repo?
If I want to work on a single app, it's hard (well, tedious and error prone) to check out a directory of a repo, so I have to check out the entire git tree (or at least clone the whole tree), so that implies that git is not really built for keeping all the app's & dependencies in a single tree.
But if I want to keep each of the projects (app's, frameworks, dependencies, doc trees, CSS) in it's own repo, then I run into chasing my tail for dependency resolution, that is, I don't know which version of each app are compatible. I think git tags are a good way to go, if only I could move them to newer versions that maintain compatibility.
When app's split or merge -- as happens often with refactoring models down to baser models -- can i move the git history of just those files to another git? I don't see how to do this, so that leans towards a single repo for it all.
If I develop a new feature across app's, it would be nice for branches to represent features.
I think I want a repo of repo's -- does that exist?
This is about using a component approach: a component being a coherent set of files which have their own history (own set of branches, tags and merges).
It should include only what cannot be generated (although the db schema can sometime be added to the repo, as seen in "What is the right approach to deal with Rails db/schema.rb file in GIT?". You still can generate it though, as shown in "What is the preferred way to manage schema.rb in git?", to avoid needless conflicts)
A component can evolve without another one having to evolve. See "Structuring related components in git".
That is the main criteria which allows you to answer: "X and Y: one or two repos?".
You can split a repo into two later, but be aware that will change their history: other contributor will need to reset their own repo to that new history.
You can group those different components repos in one with submodules, as explained here (that is the "repo of repos", or, if you want to have only one repo, in subtree, as illustrated here.
I'm looking for a tidy way to manage my cross-platform HTML+JS projects in github.
Here's my typical working process:
I complete developing my app for ios
I start working on Android platform version
I start working on XXXXXXX platform
...
From step 2 and further I come out with:
commits that can be merged in the Head repository
commits that can not be merged, so I have at least 2 versions of some of the files that compose the project
My problem is that forking/branching for each platform force me to duplicate changes on the shared part of the project too. Maybe there's something that I'm missing in both branching and forking.
Which method you use to organize your code on github so as to preserve both the differences and the unity of the project?
It sounds like branches might be the way to go: create an android branch, etc., and if you need to branch those further then create android/branch1, android/branch2 and so forth.
When you need to merge files between branches you might want to use the git cherry-pick command to select the commits to merge. I would also probably do this on a temporary local branch before pushing, to make it easy to recover from screw-ups!