I've just started working in a continuous integration environment (TeamCity). I understand the basic idea of not getting so abstracted out in your code that you are never able to build it to test functionality, etc. However, when there is deep coding going on, occasionally it will take me several days to get buildable code--but in the interim other team members may need to see my code.
If I check the code in, it breaks the build. However, if I don't check it in, my team members are unable to see the most recent work. I'm wondering how this situation is best dealt with.
A tool like Code Collaborator (Google link, smartbear.com is down..) would allow your peers to see your code, without you committing it. Instead, you just submit it for review.
It's a little extra trouble for them to run it though.
Alternatively, setup a second branch/fork of your codebase for you to work in, your peers can sync to that, and it won't break the build server. When you're done working in your own branch, you can merge it back with mainline/trunk/whatever.
In a team environment, it is usually highly undesirable for anybody to be in an unbuildable state for days. I try to break large code deliveries to as many buildable check-ins as I can. At minimum, create and check in your interfaces even if you do not have the implementation ready so others can start to code against them.
One of the primary benefits of Continuous Integration is that it shows you when things break and when things are fixed. If you commit those pieces of code that break the system, other developers will be forced to get it into a working state before continuing the development. This is a good thing because it doesn't allow code changes to be made on top of broken things (which could cause issues where a co-workers code worked on the broken system, but doesn't work once the initial break is fixed).
This is also a prime example of a good time to use branches/forks, and simply merge to the trunk when all the broken things are fixed.
I am in exactly the same situation here.. As build engineer I have this working beautifully.
First of all, let me break down the branches / projects. #Dolph Mathews has already mentioned branching and tbh, that is an essential part of getting your setup to work.
Take the main code base and integrate it into several personal or "smaller" team branches. i.e. branch_team_a, branch_team_b, branch_team_c
Then set up teamcity to build against these branches under different project headings. So you will eventually have the following: Project Main, Project Team A, Project Team B, Project Team C
Thirdly, then setup developer checkins so that they run pre-commits builds for the broken down branches.. You can find the TC plugin for this under tools and settings.. They have it for IntelliJ or VS.
You now have your 3-tier setup..
- Developer kick starts a remote-run pre-commit build from their desktop against their project. If it passes, it get's checked into the repository i.e. branch_team_a
- Project Team A passes after several check-ins; at which point you integrate your changes from branch_team_A to main branch
- Project Main builds!
If all is successful then you have a candidate release.. If one part fails, projects a, b or c. it doesn't get checked into main. This has been my tried and tested method and works everytime. It also vastly improves team communication.
Related
Hi guys! I'm new to git so this is something that keeps concerning me till now ...
As you guys already knew, below is the most popular git flow. But to me sometimes, I did have some problem with creating new feature branch from develop branch. Because if someone before me, who already committed and merged something bad into develop branch and after that, without knowing I create a new branch base on it, then I will work on a branch with potentially broken, right ?
Then in my new team, I saw a git flow like this:
Every feature branch is created from master
When a feature is complete it is merged into the develop branch (testing env)
If tester sees there's no problem with develop branch then:
A release branch is created from master
Merge all the completed feature into the release branch. (and test 1 more time on STG env)
No need to merge back release branch into develop branch. If there's any problem, fix it on feature branch and merge it into develop branch (test again) and if it's ok, merge it into release branch.
Merge release branch into master.
Doing it this way ensures that every time a new feature branch creates, it have already gone through 2 phase of testing or so I think...
Please give me advice on this one, is it good or not ? Or is there any disadvantage that I dont know. My new team has been working on this git flow for few years and there's no problem until now. But when I suggest it to my friend, they don't like the idea saying that I should have followed the popular one... I'm kinda confused right now. Thank you very much.
First of all, git-flow is just a framework. There is no reason why you should not adjust it to your needs.
But there are some disadvantages in creating branches that way:
(1) Your testers might (and most certainly will at some point) still miss a bug which then will end up on master. We are all humans and it's simply impossible - no matter how many testers and test phases you have - to produce software that is completely bug-free. master is just your new develop.
(2) The more important issue here: you always have to wait until new features are on master to continue working on them. Often bigger features are split into multiple issue / user stories / whatever to make them easier to work on. You would normally merge part 1 into develop (considering it's a shippable feature in itself) and then continue working on this using develop as your base.
This is going to be hard (meaning delayed using your master-base method).
Hi we are at a point in our wordpress website that it would seem appropriate to update the WP version. We have an existing busy site, have paid a good amount to hack plugins and core stuff to get it working the way we want it to. I'm debating the wisdom of updating the entire foundation of the site over a few minor vulnerabilities and enhancements that aren't interesting for us. My thinking is this.
The reason for upgrading appears to be because a given version may have some security issues. So you go through the painful process of updating, which usually kills all your plugins. You then spend many frustrating hours talking to plugin support people telling you 'it must be clashing with other plugins', or you take the time to / pay someone to fix everything (again).
After upgrading you have to take time to relearn the system and all the changes. You may have to adjust your workflow due to these changes, and maybe retrain your entire team. And after all that, in 5 minutes hackers find the security issues with the current version - which MAY be worse than your previous version - and you have to go through the whole operation again.
The aim of running a website is to not spend each and every day dealing with upgrade issues. The aim is to have a system that does what you need it to do, the way you want to do it. Once you have that, it's not useful to keep changing it 'just because', it's not a fashion show. It's not an iPhone, pushing users to upgrade their entire phone because they added a letter on the end of the phone name and changed the color from grey to a slightly different grey.
I am of the opinion that it is much more economical - once you have a system set up the way you need it - to just get a dev to fix any vulnerabilities in your existing WP code. And, somewhere down the line, if there was a VERY good reason you should update (e.g. major new PHP version) - then build the site from scratch and get a dev to migrate the data. This could be 7 years later or more. The time effort and money you would save doing it this way, seems a lot more logical.
Say you were building a Ford Model T in your garage. You are ordering parts from a supplier and you are halfway through the build when your supplier starts sending you parts from a Ford Capri - "Oh we are doing parts for Capris now". So you can the Model T and start building a Capri. Halfway through the build, your supplier starts sending you parts for a Mustang. And so on. You will spend your entire life half building that car and at no point end up driving the C*.
Given the performance issues of WP out the box - and the logical progression of a successful site to start migrating to a bespoke solution - it would make sense to me to take your existing WP, strip out the crap you don't need and optimize everything. At that point, it's not really WP any more, vulnerabilities fixed, and it is essentially already a bespoke solution without needing to start from the absolute ground up.
Does anyone have any thoughts on this? Serious question, we need to decide if we are going to go through all this a 4th time and I'm not really feeling it. Any input would be appreciated thanks. To make this 'it must be a specific question' I will just ask - are you a very experience WP dev, and do YOU keep jumping through the update hoop every 5 mins?
I have a lot of UI Automation JavaScript code which is no longer useable since support was dropped in Xcode.
I'm looking for any means possible to try an reuse as much of the code as possible.
I just wondered if there's is any sort of migration path or hack to make it useable ?
I haven't seen anything so far.
Well, I've waited enough for iOS QA Automation Engineers to share their professional view on the matter, but since none showed up, I'll give it a go.
First off, you are not alone. UI Automation support has been dropped since XCode 8 and a lot of other people had the same problem.
The main takeaway from all the materials I've read online is this:
The only version of Appium that will work with xcode 8 is 1.6.0. You can download the beta now. Instruments/UIAutomation have been removed and only Appium's XCUITest support will work moving forward.
Moving forward, the best document to get you started with your test case migration, or at least give you some helping tips is this one: Migrating your iOS tests from UIAutomation (iOS 9.3 and below) to XCUITest (iOS 9.3 and up) [UPDATED LINK].
The article covers some pretty hot topics considering your situation:
Element class name schema;
Page source;
Locator strategies (with xpath emphasis);
Dependencies, API differences, etc.
You will have to start using appium-xcuitest-driver instead of appium-ios-driver.
Installation & Setup:
Apart from the relevant info that you'll find on appium-xcuitest-driver's official GitHub repo, the bread and butter is here: Setting up iOS Real Devices Tests with XCUITest.
Getting started with a new framework/set of libs, or migrating from one tool-suite to another is always hard, but from past experiences, once you have a working setup and build your first test case, everything else will go smoothly afterwards.
Finally, I could pro-long the response, but the official documentation will always do a better job.
Hope is helps in any way, shape, or form. Cheers!
Recently we started using some code names for several different types of prototype applications all following a theme. This made things a little more fun and was a great idea.
The problem is that Im not too sure how people deal with migrating a codebase from "codename" state into version 1.0 state which may have a proper name... not something that a client really shouldnt see :)
We are using Visual Studio at the moment, and I can see that you can change the assembly name, but there are references to the namespaces, etc... that would really be a large change to make.
Do people bother changing things like namespaces before the v1.0 release?
I prefer to change all references including project names, folders, namespaces, everything whenever the real name changes. It can be a bit of a pain, but it's better in the long run, especially when new developers are introduced to a project and are not familiar with the history.
Some companies continue to use code names internally even after the real name is decided and released. Even today there are some places where "Opus" shows up in reference to Microsoft Word (when digging into window handle info, not any published api or ui).
If you keep code names around, you end up with a mess and a large document to have to know what is what.
http://en.wikipedia.org/wiki/List_of_Microsoft_codenames
I've always considered development names to live in a different space than the deliverable product name. Unless the development name is profane, or you are producing libraries or APIs, I don't see necessary harm from the development name appearing in a symbol table or sumptin'. (Your customers will generate their own profanities for your code, anyway ;)
Sam's answer sort of agrees with this stance, if the development names never got outside the code pit, there wouldn't be a Wikipedia page listing them.
My team works mostly w/ Flex-based applications. That being said, there are nearly no conventions at all (even getting them to refactor is a miracle in itself) and the like.
Coming from a .NET + CruiseControl.NET background, I've been aching to getting everyone to use some decent tracking software (we're using a todo list coded in PHP now) and CI; I figured trac+BuildBot would be a nice option.
How would you convince upper management that this is the way to go, as well as some of the rules mentioned in this post? One of my main issues is that everyone codes without thinking (You'd be amazed at the type of "logic" this spawns...)
Thanks
Is there anything you could do now that wouldn't require permission from anyone else? Could you start by just using trac/buildbot/etc for just your own work, then add in others as they are interested?
In my experience you can get quite far by doing w/out asking.
Tell the management that they'll be better able to keep their eye on progress with such a tool.
Are there specific benefits to the route that you're suggesting that you could show them without them having to buy in?
I had an experience with getting my team to accept a maven + cruisecontrol CI setup. Basically I tried to get them to go along with it for a few days and they kept balking because it was unfamiliar. Then I just did it on my own and had all broken builds emailed to the mailing list. That night the project lead made a check in that broke the build (he just forgot a file) and, of course, everybody was emailed with his screw up.
The next day he came over to me and said, "I get it now."
It required no effort from him to get involved and got to see the benefits for free.